2.1.不断变化的客户需求。
2.2.软件项目无法避免的挑战。
2.3.产品需求和环境会随时间而变化，您的应用程序也必须随之变化。
2.4.不断变化的需求可能会导致不稳定并破坏开发工作。
2.5.通过构建渐进式架构来适应不断变化的需求。
2.5.1.进化架构避免了复杂性，而复杂性是进化的敌人。
2.5.2.矛盾的是，在软件中实现简单性可能很困难。
3.1.复杂系统的特征。
3.1.1.高依赖性。
3.1.1.1.该软件依赖于其他 API 或行为。
3.1.1.2.依赖显然是不可避免的，甚至是可取的，但它必须是平衡的。
3.1.1.3.依赖性高的系统很难修改。
3.1.1.3.1.它们紧密耦合，具有高度的变化放大。
3.1.1.3.2.紧耦合是指模块之间严重依赖，导致更高的变化放大，即需要修改依赖关系的单个变化。3.1.1.4.经过深思熟虑的 API 设计和对抽象模型的克制使用将最大限度地减少紧密耦合并改变放大效应。
3.1.2.隐蔽性高。
3.1.2.1.是什么让程序员难以进行更改，以及需要更改什么。
3.1.2.2.晦涩难懂的**需要更长的时间来习，开发人员更有可能无意中破坏某些东西。
3.1.2.3.症状。
3.1.2.3.1.“知道”太多对象。
3.1.2.3.2.鼓励 *** 全局状态。
3.1.2.3.3.掩码的过度间接寻址 **。
3.1.2.3.4.影响程序远程行为的远距离操作。3.1.2.4.采用具有明确约定和标准模式的 API 可以减少模糊性。
3.1.3.高惯性。
3.1.3.1.指软件保持其以前的习习惯。
3.1.3.2.**用于快速实验，容易丢弃，惯性低。
3.1.3.3.为十几个业务关键型应用程序提供支持的服务具有很高的惯性。
3.1.3.4.复杂性的成本会随着时间的推移而增加，因此具有高惯性和高变化的系统应该被简化，而具有低惯性或变化的系统可以保持复杂（只要你放弃它们或继续保持它们不变）。
3.2.复杂性并不总是能摆脱它，但你可以选择把它放在**中。
3.2.1.向后兼容的更改可以使它更易于使用，实现起来更复杂。
3.2.2.用于解耦子系统的间接层减少了依赖性，但增加了隐蔽性。
4.1.未知未来的需求策略。
4.1.1.试图预测未来的需求。
4.1.2.构建一个抽象模型作为逃生舱口，以便于后续修改。
4.1.3.将导致复杂性增加。
4.2.接吻的原则。
4.2.1.让事情变得简单。
4.2.2.使用 KISS 方法，请记住以简单为核心原则构建系统。
4.2.3.简单性允许您在未来增加系统的复杂性。
4.3.保持简单的最简单方法之一是避免编写所有内容。
4.3.1.告诉自己你不需要它（yagni）。
4.3.2.使用最小意外原则和封装原则。
4.4.不要构建你不需要的东西。
4.4.1.通过猜测来编写将继续使事情陷入困境，它需要维护，开发人员需要理解它，它必须被构建和测试。
4.4.2.避免过早优化、不必要的灵活抽象模型以及最小可行产品 （MVP） 不需要的产品功能。
4.4.3.过早优化是指开发人员在证明有必要之前优化性能。
4.4.4.灵活的抽象模型 – 插件架构、封装接口和通用数据结构（如键值对）是另一个模型。
4.4.4.1.抽象是有代价的：它将实现框定在严格的边界中，开发人员最终会与之抗争。
4.4.4.2.灵活性也使阅读和理解变得更加困难。
4.4.4.2.1.保持灵活性的最佳方法之一是减少总金额。
4.4.4.2.2.咀嚼方法将使您的软件保持“纤薄”和适应性强。4.4.5.MVP 允许您首先测试一个想法，而不必押注于成熟的实现。
4.4.5.1.将接口填充码放在您怀疑可以插入优化的地方，但实际上并没有实现它们。
4.5.最小意外原则。
4.5.1.不要让用户感到惊讶，构建功能的行为与他们最初预期的一样，具有升高的 习 曲线或奇怪行为的功能可能会让用户感到沮丧。
4.5.2.不要让开发人员感到惊讶，令人惊讶的是，他们往往晦涩难懂，这会导致复杂性。
4.5.3.通过保持目标明确、避免隐性知识以及使用标准库和模式来消除意外。
4.5.4.开发人员在调用 API 时需要知道的任何非显而易见的知识，但不属于 API 本身，都被视为隐性知识。
4.5.5.对排序的需求决定了某些操作必须按特定顺序执行。
4.5.5.1.使用文档来说明一些排序要求是个好主意，但最好一开始就不要有它们。
4.5.6.当方法的签名意味着比该方法实际可以接受的更广泛的有效输入时，就会出现隐藏的参数要求。
4.5.7.请记住，要使您的参数要求具体化和可视化。
4.5.7.1.使用能够准确适应约束的特定类型，在使用 JSON 等灵活类型时，请考虑使用 JSON 架构来描述预期的对象。
4.5.8.使用标准库和开发模式。
4.5.8.1.请使用通常的风格和开发模式。
4.6.包装领域的专业知识。
4.6.1.将软件组件映射到业务领域将使变更保持集中和干净。
4.6.1.1.会计、计费、运输等
4.6.2.封装领域自然倾向于高内聚和低耦合。
4.6.2.1.理想的功能。
4.6.2.2.具有高内聚和低耦合的软件更有可能发展，因为变化的“半径”往往更小。
4.6.2.3.解耦**是自包含的，对其逻辑的更改也不需要对其他软件组件进行更改。
4.6.3.开发人员通常从“层”的角度来考虑软件：前端、中间层和后端。
4.6.3.1.每一层都有自己的团队，这增加了编排成本，因为业务逻辑的每次更改都会影响所有软件层。
4.6.4.识别领域边界和封装领域知识既是一门科学，也是一门艺术。
4.6.4.1.领域驱动设计 （DDD），它定义了一组广泛的概念和实践，这些概念和实践将业务概念映射到软件。
4.6.4.2.只有在最复杂的情况下才需要完全覆盖 DDD
4.6.4.3.熟悉 DDD 将帮助您做出更好的设计决策。