介绍

软件系统架构是系统关键组件的组织结构，这些组件通过接口交互，并由较小的组件和接口依次组合而成。

没有架构基础，系统将会以低效、偶然的方式演进。这样的系统常常被证明难以扩展、重用，或没有大量返工的进行集成。这对组织团队，或者是在没有架构提供共同的技术焦点的情况下进行沟通交流来说，也是困难的。

尽早聚焦于架构从而最小化风险和组织开发。

实践

为你今天已知的创建架构

爱因斯坦说过，让一切尽可能的简单，但不能超过简单的极致（make everything as simple as possible, but no simpler）。软件项目是资源受限的，期望开发者创建优雅的解决方案可能导致系统的复杂度超出利益相关人的要求。在混乱或不确定的环境中开发所谓“面向未来”的系统，将可能导致代码臃肿，增加了总体成本以及复杂度却很少有真正的收益。

为当前已知的需求创建架构，处理利益相关的真实需求，并提供适当的灵活性和速度。避免奢求，以及任何用心良苦的推测未来需求的行为，那将导致架构过度化。过度设计架构和构建灵活可扩展的架构之间是有区别的。例如，可能没有明显的理由为系统创建一个三层架构，但是系统可能会以我们无法预测的方式发展到需要的地步，因此我们应该创建三层架构。

利用架构作为协作工具

开发者们如果缺乏对系统的共同理解将导致他们之间犹豫不决以及互相矛盾的意见，并能迅速使项目陷入瘫痪。并且，开发者们还可能对系统有不同的心智模型，彼此的工作南辕北辙。

创建和演进系统架构的意图是使用它来保持开发者们一致的系统心智模型。一个好的架构通过提供统一的术语表做为所有和系统有关的讨论的基础，来帮助开发者之间的协作。

通过提高抽象层次应对复杂性

软件开发充满了复杂性，而人们处理复杂性的能力是有限的。当系统变得更大时，将使开发团队很难发展对系统的共同理解，因为很难看到全貌。

使用模型来提供抽象的层次从而聚焦于高层决策，例如关系和模式，而不是陷入细节。建模提高了抽象的层次，并且使得更容易从不同的角度理解系统。

组织架构为松散耦合、高内聚的组件

组件之间的紧密耦合将使用系统变得脆弱且难以理解。软件的创建是昂贵的，因此，如果可以重用现有的组件，将可能减少创建系统的工作量。

使用最大化内聚和最小化耦合的组件来组织系统架构。这将提高对系统的理解，并增加灵活性和重用的机会。

重用现有资产

当你可以简单的重用、下载甚至购买时，构建是一种浪费。

尽一切努力来重用现有资产。开发人员常常不愿意重用资产，因为这些资产并不能完全满足他们的需要，或者这些资产的质量低劣。做好使用重用资产的权衡，你可以实现使用现有资产来节约工作量，即使使用这些资产可能需要进行调整或放宽约束。