现在该重新审视多年来保持不变的假设了。 动态变化的世界决定了自己的规则，包括计算机体系结构。 发生的变化需要新的方法，迫使刚性系统变得灵活并适应新的条件。 如果一切都在不断变化，是否可以进行长期规划？ 如何防止架构解决方案随着时间的推移逐渐退化？ 在这里，您将找到答案和建议，以在不断变化的情况下保护项目的最重要特征。 “这是当前对问题的理解的重要里程碑。 随着人们意识到软件在21世纪的作用，有关如何在保持已取得成果的同时如何应对变化的信息已成为软件开发中的一项基本技能。” -马丁·福勒
进化架构：陷阱和反模式
我们花了很多时间讨论架构中适当的连接级别。 但是，我们也生活在现实世界中，并观察到许多相互影响的项目，削弱了项目的发展能力。
已经确定了在软件项目中显而易见的两种不良设计实践：陷阱和反模式。 许多开发人员使用“反模式”一词作为the语“坏”，但是其实际含义需要澄清。 反模式软件包括两个部分。 第一部分：反模式是一种实践，最初似乎是一个好主意，但后来变成了错误。 第二部分：对于大多数反模式，有很多更好的替代方法。 架构开发人员仅在回顾时才注意到许多反模式，因此很难避免它们。 陷阱乍一看似乎是个好主意，但立即表明这是一个不好的方法。 在本章中，我们将一起讨论陷阱和反模式。
技术架构
本节重点介绍行业中常用的实践，这对团队的体系结构开发能力特别不利。
反模式：供应商王一些大型企业购买企业资源计划（ERP）软件来解决常见的业务任务，例如会计，库存管理和其他常规操作。 如果公司准备改变其业务流程和其他解决方案以适应此工具，则此方法有效，并且当体系结构开发人员了解其局限性和优势时，可以策略性地使用该方法。
但是，许多组织对此类软件过于雄心勃勃，这导致了供应商之王的反模式，其架构完全基于供应商的产品，这在病理上将组织绑定到此工具。 购买供应商软件的公司计划增加带有插件的软件包，以扩展基本功能，使其与企业主题领域保持一致。 但是，很长一段时间以来，ERP工具的配置不足以完全实现所需的功能，并且由于该工具的局限性以及使它们成为建筑世界的中心，开发人员发现自己无能为力。 换句话说，建筑的开发者决定了其建筑之王的供应商，从而决定了未来的决策。
为了避免使用反模式，即使软件起初具有广泛的职责，也应将其简单地视为另一个集成点。 假设整合处于初始阶段，则更容易通过其他整合点来改变无用的特性，从而将国王从王位上推翻。
通过将外部工具或平台置于体系结构的最核心，开发人员大大限制了他们在两个主要方向上的发展能力，即技术上和从业务流程的角度。 在存储系统，受支持的基础架构以及许多其他限制方面，开发人员在技术上受到供应商选择的限制。 从主题区域的角度来看，大型封装工具最终会遭受“最后10％的陷阱”反模式的影响。 从业务流程的角度来看，该工具无法支持最佳工作流程； 这是最近10％的副作用或陷阱。 大多数公司通过提交给平台，替换流程而不是尝试自定义工具来关闭。 公司执行的次数越多，公司之间存在的特色就越少，这是很大的，因为差异不是优势。
让我们停下来工作并称之为成功的原则是开发人员在现实世界中处理ERP软件包时通常考虑的原则之一。 由于它们需要大量的时间和金钱投资，因此公司在不工作时不愿意接受它们。 没有任何技术部门愿意接受数百万美元的损失，并且该工具的供应商也不想接受不良的多层实施。 因此，各方都同意停止工作并称其为大多数未兑现的承诺功能都成功。
不要将您的架构与供应商之王联系起来。
不要将供应商产品视为另一个集成点，而不是沦为供应商国王的反模式的猎物。 通过在集成点之间建立抵抗破坏的层，开发可以将供应商工具的更改与体系结构的影响隔离开来。
陷阱：漏洞抽象
所有非平凡的抽象都在一定程度上充满了漏洞。
-乔尔·斯波斯基（Joel Spolsky）
现代软件基于抽象塔：操作系统，平台，依赖项等。作为开发人员，我们以某种方式构建抽象，使我们无法在较低层次上不断思考。 如果开发人员需要将硬盘驱动器中的二进制数字转换为程序的文本，则他们将无能为力！ 现代软件的胜利之一是我们可以如何构建有效的抽象。
但是抽象是昂贵的，因为没有完美的抽象，如果是的话，它们将不是抽象，而是真实的东西。 根据Joel Spolsky的观点，所有非平凡的抽象都有一个漏洞（泄漏）。 这对开发人员来说是个问题，因为我们认为抽象总是准确的，但是抽象常常会崩溃。
最近，技术堆栈的复杂性日益提高，抽象已成为一个灾难性的问题。 在图。 7.1展示了可追溯至2005年左右的典型技术堆栈。
在此堆栈中，块上的供应商名称根据当地情况而变化。 随着时间的流逝，随着软件变得更加专业化，我们的技术堆栈也变得越来越复杂，如图2所示。 7.2。
如图所示。 7.2，软件生态系统的每个部分都已扩展并变得更加复杂。 随着开发人员面临的问题变得越来越复杂，他们的解决方案也越来越复杂。
最初的有孔抽象 ，即低级别的破坏性抽象会导致意外的混乱，是增加技术堆栈复杂性的副作用之一。 如果最低级别的抽象之一失败了，例如，看似无害的数据库调用带来了一些意外的副作用，该怎么办？ 由于层数太多，此故障将移至堆栈的顶部，可能会导致其路径中的“转移”，并在UI中深层嵌入的错误消息中体现出来。 技术堆栈越复杂，调试和回顾分析就越困难。
尝试充分理解至少比您通常工作的级别低的抽象级别。
-鼠尾草软件
尽管了解下面的层是一个很好的建议，但是随着软件的专业化和复杂性的增加，遵循它变得越来越困难。
增加技术堆栈的复杂性是动态均衡问题的一个例子。 随着时间的流逝，不仅生态系统发生了变化，而且其组成部分变得更加复杂和混乱。 所提出的保护变化的机制，即适应性函数的使用，可以保护体系结构连接的脆弱点。 架构师在关键集成点（如适应性函数）定义了不变式，这些不变式作为部署流水线的一部分工作，从而确保抽象不会以不良的方式开始流动。
»这本书的更多信息可以
在出版商的网站上找到对于habrozhitelami优惠券20％的折扣-
进化建筑