软件架构就是在软件开发领域，实现软件系统目标的一个架构。当一个人新进入一个系统的时候，首先要摸清的就是这个系统的架构，从形式上去理解内容，从分析其部分到综合其整体。
一个软件系统是为了满足特定的功能需求。正如一个组织部门是为了完成一项事业。这都是在成事的层面。背后则是真正的推动力量必然是人， 是利益相关者。在政治上，是领袖，领袖的联盟成员即领袖的班底，各级官僚，老百姓等。在软件系统的利益相关者，用户客户，项目经理，开发、运维。甲方乙方各自是一个系统，又因为一个软件系统联结成为一个共同的系统。
为了解决特定问题，就需要对问题进行建模，模型就是人们在长期的解决问题过程中，形成的经验套路。为了能让甲方满意，就要找到甲方的关注点，即要需求分析，进而成为软件系统的关键约束，达成人之间的契约约束。
架构并不神秘。它是工程学，而非科学。在科学的世界里，对就是对，错就是错，容不得半点妥协；而在工程的领域里，妥协随处可见。所以没有完美的架构，只有合适的架构。两个差别很大的架构，当不给定context时，我们不能说架构A一定优于架构B。
很多软件工程师在一线开发岗位呆了十年八年，却未被贴上架构师的标签，只因为他们还没有找到属于自己的做架构的机会；而那些高高在上，张口闭口modularity，clean architecture，etc. 却一行代码不肯写也不肯读的所谓的『架构师』们，实在不配获此title。
架构的能力是在实战中演练出来的，是逢山开路，遇水搭桥，踏着荆棘一步步写出来的，跟优秀的作家产生的道路几乎一模一样。然而，优秀的作家，即便获得了诺贝尔奖，还一定还会笔耕不辍，自己撰写一部又一部新作品。那么，『架构师』，程序员中的佼佼者，为何就脱离生产线，变成了高高在上的指挥者？
这真是软件公司，尤其是大型软件公司让人绝望的怪状。还好，就像1984 macintash的广告一样，新生代的twitter们在冲击着这个世界。架构和架构师们开始回归其本质：产品和生产它们的程序员。
原文地址：https://www.cnblogs.com/doit8791/p/9485108.html