按：但凡是从事软件研发甚至是软件相关行业的人，想必无一例外谈起软件架构都能发表自己的观点。有点经济学的感觉了，每个人都有观点，每个观点都看似合理，哪怕互相矛盾的观点。这种现象甚是奇妙。但是，从作者接触的大多数同行来看，大多数的观点大体可以分为两个，一个是这个软件架构好，那个软件架构不好。如此复杂的一个问题，最后被归纳为两个绝对的评价，显然这是偏颇的。即使是最差的软件，也可能拥有局部好的架构或者说设计，相对应的是，即使成功的软件产品，也可能存在局部较差的架构设计。因此，探明软件架构的本质，进而能形成对架构的客观合理判断。要遵循两个重要原则：1. 软件架构是一个综合效应，是软件活动中最困难的阶段；2. 软件架构存在一个最终的可直观判断结果，但是无法对其本身下一个绝对的结论。文章会尽作者所能探明这个问题。
软件架构是软件构成的主旨结构，以及采纳该主旨结构的人（架构师）在设计时对问题域所持有的主要观点和看法，以及他们坚持的原则。软件架构由人（架构师）主观创造，解决客观的问题。是的，任何一个软件架构无论优劣，都是相对于其所特定的问题独一无二的解。
{2018.8.13 update} 从架构师决定软件架构的角度来看，可以分为主观判断、客观选择两部分。主观判断包括了架构师（以及团队）对问题域理解，以及由此产生的软件设计要素，诸如架构分层、模块划分、API设计、数据模型设计，也就是通常所说的应用架构、信息架构和开放架构；甚至架构方法的选择，如是否采用DDD来建模，交流、描述整个软件的架构设计；主观设计是架构师（团队）根据个人经验以及对问题域的理解做出的一系列架构的决策。这部分架构设计对软件产生深远的决定性的影响，也是架构师（团队）的核心能力、价值体现。它产生的过程依赖人，是主观的，但是结果却是客观的，影响是决定性的。包括依据Conway定律，决定了研发团队的组织结构。依据开放能力水平，决定了软件产品的可持续发展演进能力和对变化的适应能力（如Linux已经演进了近30年还在持续）。主观判断关注点是设计，核心任务是根据实际需求构思出抽象的概念结构（人月神话语），特征是想象出最佳解决方案；从需求到设计的约束来自于需求，弹性较大，可把握的难易程度较大，来自于软件本身的使用价值。这一部分把软件视作解决问题的目的载体，考验的是架构师对问题领域的分析能力以及抽象思维逻辑能力。
客观选择是架构师（团队）根据对现有技术的把控和理解，选择一系列技术栈来实现主观判断产生出来的软件要素，诸如采用Spring Cloud来构建应用，选择MySQL作为数据库平台，选择AWS抑或阿里云作为部署平台等等，也就是通常所说的技术架构。这一部分还包括一些特殊的看似主观的判断，主要指一系列设计模式的应用，如采用Circuit Breaker来做服务的容错设计等等；因为模式本身是固定存在的，一旦使用，就遵循固定的范式。所以也是技术架构。对性能优化、部署、运维效率提升而采用的一些技术措施也属于技术架构的范畴。架构设计客观选择部分的特点是，利用已有技术能力来确定软件的实现路径，包括软件功能性和非功能性能力（性能、体验、运维效率等）的实现。这部分对软件质量的好坏、研发团队的工具链&效率、产品构建周期长短、软件维护的代价、软件的开发&使用成本等有直接的影响。客观选择的关注点是实现，核心任务是根据设计选择恰当的技术来实际开发、部署软件，使软件能够真正运行、被使用。特征是完成设计到实现的具体映射；从设计到实现的约束来自于需求和技术两个方面，表现为取得技术和需求共同约束的平衡，比较具体，弹性相对小，可把握的难易程度较小。这一部分把软件视作待加工的产品构件，考验的从架构设计到工程的实践能力。
需要特别说明的是，以上主客观的划分是可以解耦来看的，但划分不是绝对的，只是根据架构任务的主要目标不同进行的分类。架构本身是一个系统化的抽象复杂概念结构，是一个整体。相互制约，比如技术架构的约束可能影响主观判断的变化，如从字段到整表数据冗余场景可以轻易的破坏掉第三范式的设计，性能的要求带入大规模缓存使用让我们不得不放弃完美的一致性追求，广为人知的CAP定理只能提供三选二的选择等等。在以上架构任务之上，架构师更应该拥有系统化思维，为主观判断选择客观合理的实现路径；拥有持续反馈优化的思维，根据客观实现不断优化主观抽象概念设计。相辅相成，进而完成一个最佳的trade-off，打造精良的软件产品。这是架构的复杂性所在，也是架构师的核心价值所在。
主客观的架构观点，跟《人月神话》的软件的根本任务和次要任务的划分观点也是一致的。《人月神话》中“软件的根本任务是打造抽象复杂的概念结构”本质上是架构的主观设计部分，它完全依赖于人，拥有最大的不确定性和复杂性。
根据商品的使用价值理论，一个完整的软件产品必须解决某个领域特定的问题。据此，每个软件产品的架构就会呈现出独特的特征和关注点，比如手机终端的APP就会非常关心资源占用、能耗和UED体验等，而一款企业应用则会把快速实现商业逻辑作为首位，不会把能耗作为首要考量因素。即使针对同样的架构维度比如性能，手机APP聚焦在内存占用、电池的优化，而企业应用聚焦在数据的处理、应用部署的结构等。
但是，软件本身也有其共同的本质，比如性能、稳定、正确、有较大的自定义功能的便捷性。这些从架构维度思考，又有统一的思考方法和方式。
因此，软件架构具有独特性、同时也具有共通性。
软件产品的领域
就像创造一篇诗词或者写一篇议论文一样，一个软件架构的好坏首先取决于作者是否深刻理解了命题的主旨一样。比如写中秋诗词，主旨是思念亲人、思念故乡还是启发哲思，就能完全得到三组不同的词句“”“”“”，而写作手法却有相似借鉴之处。因此，理解主旨，也就是问题域，是真正区别好架构和劣质架构的根本标准。由此看来，劣质架构本身的技术特征或许并不坏，只是不适合它所要解决的问题。这是架构师是否成为架构师需要理解的第一奥义。
此篇阐述了微软ｏｆｆｉｃｅ３６５系列云架构转型的思路和历程，从结果上看，其架构的选择应该是正确的。（仅供参考）
橘生淮南则为橘、生于淮北则为枳，在一个没有生命力的领域产生优良的架构几乎是领概率事件。
领域还包含另一层更重要的意义，就是上下文。跟你问题域相关的那些客观问题或者影响因素，也是架构需要密切关注的。因为软件本身也不是孤立存在的程序实体。一款有现实使用价值的软件产品必须和其他软件协同工作。
软件架构的政治问题
架构团队与领导的连接处理问题
软件架构的落地实现问题
- 架构团队的贵族专制制度，包括架构团队的团结程度、影响力与威信
- 架构团队所在的软件研发队伍素质
- 架构团队本身的闭环能力
- 软件架构师应该知道如何更好的选择和应用技术
软件架构尽管有很强的主观成分。但是软件毕竟还是要一行行代码去实现。采用什么样的框架、中间件服务，运行时平台的规格等等，都是动手写代码的基础。选择什么样的关键技术，也是对架构师水平的考量。因此，软件架构师需要对关键技术有较强的把握能力才能将主观的“架构”变成实实在在的软件，使最终软件支撑架构设想，呈现出架构期望达成的目标。
软件架构的演进发展问题
常常有观点说，架构是演进出来的。这种观点本身揭示了软件架构的一个特征是，软件架构必须有生命力，就这一点上来说，是正确的。但是，仔细思考，演进的原点在哪里？原点从哪里来？这个观点的深层次矛盾似乎不如其字面这么直观。其原点本质上还是“设计”出来的，或者说是一种选择。比如软件采用容器还是虚拟机，采用ｊａｖａ还是Ｇｏ，这些都是一种架构原点的选择。而选择从哪里开始，往往对架构的功力有很广很深的考量和要求。
架构师的个人素质
并非每个人都适合做架构师，也不是你技术玩的溜就适合做架构师，架构师作为一个特定的行业职责，其倾向于具有以下素质的人。
产品精神，交付类的项目产生不了架构师。
产品精神的直观表现就是产品视角。当一个软件架构师在解决问题时，看到的是解决问题需要什么能力、特性，以及解决这个问题的能力特性需要有什么样的表现。而不是直觉式的思考技术实现方面。这时就具备了产品视角。否则只是技术视角，关注的还是实现，不是解决问题的能力构建。
商业理解力
客户理解力
洞察与分析能力
对技术的热爱
具有逻辑思维
信念与理想主义，也被说成是情怀。
具有较强的目标感。
怎么样能产生成功的软件架构？
首先要明白问题域，就是对待解决的问题要有一个清晰的判断和认识。进而想办法去解决它，这个时候才会涉及到架构选择的各个方面。