IT架构上的5分：良好软件架构的三个定律

体系结构决策的问题在于它们会影响整个系统，并且/或者您经常需要在开发过程的早期就将其制定出来。 如果您在几个月后更改该决定，则需要付出很多努力。 从经济角度来看，架构决策通常是不可撤销的。 好的架构可以使架构师做出较迟的决策，而不会对工作和成本产生明显的影响。 让我们记录下来。

法则1：好的架构是使建筑师能够做出最少的，不可撤销的决定的架构。

为了最大程度地减少不可撤销的决策，系统需要对变化做出响应。 我从软件开发项目中学到了一个重要的教训：除了改变，没有什么是永久的。 客户改变了他对需求的看法。 利益相关者改变他们对重要事物的看法。 人们加入并离开项目团队。 改变本身并不会改变的事实使我想到了良好架构的第二条规则，即：

法则2：要使决定可撤销，您需要设计灵活性。

这是最具挑衅性的声明，我在这里进行有争议的讨论。 原因是灵活性引入了抽象需求。 抽象使用简化策略，其中先前的具体细节含糊不清，含糊不清或不确定（来自Wikipedia ）。 这种简化过程并非总是容易做到的，尤其是对于其他人而言，是遵循的。 “使某些事情易于更改会使整个系统更加复杂，而使所有内容易于更改会使整个系统非常复杂。 复杂性使软件难以更改。” 来自M. Fowler的文章 ）这是构建良好软件体系结构的核心问题：开发易于更改但同时易于理解的软件。 有几种概念试图解决这个矛盾问题： 设计模式和面向对象的设计原则 。 多态性，松散耦合和高内聚性是我的灵活性促成因素。

法则3：要利用灵活性，需要无情地重构。

灵活性本身并不是目的。 您需要积极利用灵活的设计。 如果有什么变化，并且使先前的设计或体系结构决策过时，则需要进入代码并更改软件。 否则，构建灵活软件的工作将毫无用处，技术债务可能会导致延迟交付和维护噩梦。 您对代码库采取了严格的措施，这一事实要求您不断地反馈有关软件质量的信息。 因此，为了能够进行重构，必须有足够数量的自动化测试来覆盖代码库。 在理想情况下，所有内容都集成到一个持续集成环境中，以接收有关代码库运行状况的永久反馈。

参考：来自我们JCG合作伙伴 Niklas的“关于IT架构的5分：良好软件架构的三大法则”。

翻译自: https://www.javacodegeeks.com/2012/05/5-on-it-architecture-three-laws-of-good.html