第三部分：领域驱动设计的柔性设计思想

目录

1. INTENTION-REVEALING INTERFACES（释意接口）

2. SIDE-EFFECT-FREE FUNCTION（没有副作用的函数）

3. ASSERTION（断言）

4. CONCEPTUAL CONTOUR（概念轮廓）

5. STANDALONE CLASS（独立类）

6. CLOSURE OF OPERATION（闭合操作）

7. 声明式设计

8. 声明式设计风格

9. 切入问题的角度

---

1. INTENTION-REVEALING INTERFACES（释意接口）

概念

   释意接口是一种设计原则，要求接口的命名和设计应明确表达其用途和行为，以提高代码的可读性和可维护性。

目的

• 使代码更易于理解，减少对实现细节的依赖。
• 促进开发者之间的沟通，确保设计意图的一致性。

实践

• 使用有意义的命名，反映类或方法的效果和目的。
• 保持命名与团队的通用语言（UBIQUITOUS LANGUAGE）一致。
• 在编写实现前通过测试驱动开发，从客户的角度考虑接口的设计。

价值

• 接口的每个公共元素都是沟通设计意图的机会。
• 封装复杂机制，使接口只表明意图而非实现方式。

2. SIDE-EFFECT-FREE FUNCTION（没有副作用的函数）

概念

   将操作分为命令（修改系统状态）和查询（获取信息），并强调函数应当无副作用，即多次调用返回相同值且不影响系统状态。一个没有副作用的函数是指在执行过程中不会改变任何外部状态（如全局变量、静态变量等）并且不依赖于外部状态的函数。

目的

• 减少复杂系统中操作的不可预测性。
• 简化测试，降低风险。

实践

• 将命令和查询分离，确保修改状态的方法不返回领域数据。
• 使用不可变的VALUE OBJECT来表示计算结果，避免副作用。

价值

• 提供安全的操作组合，增强代码的可预测性和可维护性。

3. ASSERTION（断言）

概念

   使用断言明确表示操作的副作用，包括后置条件（操作后的结果）和前置条件（操作前必须满足的条件）。

目的

• 描述状态而非过程，简化分析。
• 帮助理解操作或对象的使用后果。

实践

• 表述清楚操作的后置条件和类及聚合的固定规则。
• 如果编程语言不支持直接编写断言，则通过自动单元测试或文档来明确。

价值

• 加快开发人员的学习过程，避免代码矛盾。
• 使开发人员易于推断出预期的断言，理解操作或对象的后果。

4. CONCEPTUAL CONTOUR（概念轮廓）

概念

   概念轮廓是认识到领域模型中存在的逻辑一致性，并在设计中反映出这种一致性的方法。

目的

• 避免功能重复和混淆概念。
• 达到模型与领域的一致性。

实践

• 通过反复重构，使设计适应新的理解和需求。
• 调整设计元素（操作、接口、类和聚合）以形成内聚的单元。
• 在重构过程中观察变化规律，寻找底层的概念轮廓。

价值

• 提升设计的柔性，增强对变化的适应能力。
• 使模型与领域的一致部分相匹配，形成有效的知识体系。

5. STANDALONE CLASS（独立类）

概念

独立类是一个尽可能减少依赖关系的设计模式，使类仅与基本类型和基础库概念相关联。

目的

• 简化模型和设计，提高理解、测试和维护的易性。
• 控制模块内部的依赖，减少设计复杂度。

实践

• 对每个依赖关系进行质疑，直至证实其必要性。
• 从模型中提取独立的关联和操作。

价值

• 降低理解和处理模块的认知负担。
• 通过独立类的设计，提高对象设计的低耦合性。

6. CLOSURE OF OPERATION（闭合操作）

概念

   闭合操作是指在一个集合内部进行的操作，其结果仍然属于该集合。

目的

• 提供高层接口，减少对其他概念的依赖。
• 简化操作的可预测性和理解性。

实践

• 定义操作时，使返回类型与参数类型相同。
• 在VALUE OBJECT中寻找大多数闭合操作的实现。

价值

• 减轻开发人员理解操作的认知负担。
• 促进软件设计的意图明确性和预测性。

7. 声明式设计

概念

    声明式设计是一种编程范式，其中程序的逻辑表达为一系列声明，描述了应该完成什么，而不是如何完成。这种设计方式强调了编写代码的目的或目标，而不是编写具体的指令来实现这些目标。

特点

• 高级抽象：声明式设计允许开发者编写更加抽象的代码，通常更接近自然语言或逻辑表达。
• 可读性强：代码更容易理解，因为它描述了目标或意图，而不是具体执行步骤。
• 减少副作用：声明式代码倾向于避免副作用，使得代码更可预测，更易于测试和维护。
• 模块化和可组合性：声明式设计通常使得代码更容易模块化和重用，因为代码片段描述的是“做什么”而不是“怎么做”。

对比命令式设计

     声明式设计与命令式设计相对立。命令式设计关注具体的实现步骤和算法逻辑，而声明式设计关注结果和规格说明。命令式代码告诉计算机如何执行任务，而声明式代码告诉计算机应该达到什么样的结果。

应用

• 数据库查询语言：如SQL，它允许用户声明他们想要检索的数据类型，而不需要指定如何在数据库中导航或如何执行检索。
• 函数式编程：如Haskell或Erlang，它们鼓励使用表达式而不是语句，并且强调不变性和函数的无副作用特性。
• 配置管理：如Terraform或Ansible，它们允许用户声明基础设施的最终状态，而不是编写达到该状态的具体步骤。

价值

• 简化复杂性：通过将关注点从如何实现转移到要实现什么，声明式设计简化了复杂性管理。
• 提高开发效率：开发者可以更快地编写和维护代码，因为他们不必担心实现的细节。
• 更好的维护性和扩展性：代码的声明性质使得未来的修改和扩展更加容易。

   声明式设计通过其高层次的抽象和对意图的清晰表达，提供了一种更简洁、可维护和易于理解的编程方式。

8. 声明式设计风格

概念

   声明式设计风格是一种编程范式，它强调的是“做什么”（what）而不是“怎么做”（how）。这种风格要求程序员声明他们想要的结果，而不是详细说明如何通过算法或控制流来实现这个结果。

对比命令式设计风格

• 命令式设计风格关注于如何执行任务（控制流、循环、条件等）。
• 声明式设计风格仅描述想要的结果，隐藏了执行细节。

9. 切入问题的角度

分割子领域

• 逐步处理设计，而非一次性完成。

尽可能利用已有的形式

• 利用已建立的概念系统，进行修改和利用。

把命令和SIDE-EFFECT-FREE FUNCTION分开

• 分离命令和查询，简化设计。

把隐式概念变为显式概念

• 明确表达隐含的概念，增强模型的表达能力。

价值

• 提升软件对变更和复杂性的处理能力，实现柔性设计。