《领域驱动设计》读书笔记

读书笔记

什么是 DDD？

DDD 是领域驱动设计（Domain-Driven Design）的简称。

美团技术团队的文章：领域驱动设计在互联网业务开发中的实践，对DDD的解读很深刻。

个人感悟

《领域驱动设计》是一本好书，应该是到达一定境界后，站在架构师的角度实践后才能够获益的好书。我看完这本书有点懵，在中国的互联网开发中，并不会有像书中为了设计一个PCB软件而讨论需求几个月的情况。现实情况是：小步快跑，快速迭代。

DDD和面向对象编程模型没有什么区别，很多技巧也是我现在正在使用的。不使用DDD，项目的代码就会随着时间的推移腐烂吗？不使用DDD，项目就会变得难以维护吗？我感觉只要遵循良好的设计原则和编码实践，这些都不是问题。

当然是因为我现在的水平不够，这确实是一本好书。过段时间后再重读一遍。

读书笔记摘抄

超订规则是一个策略，如图1-10所示。策略（policy）其实是STRATEGY模式[3] [Gamma et al.1995]的别名。我们知道，使用STRATEGY的动机一般是为了替换不同的规则，虽然在这里并不需要这么做。

现在所有人都清楚超订是一个独特的策略，而且超订规则的实现即明确又独立。

程序员可以向业务专家展示技术工件，甚至是代码，但应该是领域专家（在程序员指导下）可以理解的，以便形成反馈闭环。

虽然领域专家对软件开发的技术术语所知有限，但他们能熟练使用自己领域的术语——可能还具有各种不同的风格。

在每个对话场景中，注意观察讲话者有多少内容是谈论软件的业务功能，有多少内容是从技术上谈论软件的工作机理的。用户和开发人员用的是同一种语言吗？它的表达是否丰富，足以应对应用程序功能的讨论？

我们需要反复研究领域知识，不断重构模型，才能将领域中重要的概念提炼成简单而清晰的模型。

最早将用户界面层与应用层和领域层相连的模式是MODEL-VIEW-CONTROLLER（MVC，模型—视图—控制器）框架。

假设一个项目只需要提供简单的功能，以数据输入和显示为主，涉及业务规则很少。项目团队也没有高级对象建模师。

大部分灵活的编程语言（如Java）对于小型应用程序来说是大材小用了，并且使用它们的开销很大。

很多对象不是通过它们的属性定义的，而是通过连续性和标识定义的。

我们如何知道一个由其他对象组成的对象从哪里开始，又到何处结束呢？

当创建一个对象或创建整个AGGREGATE时，如果创建工作很复杂，或者暴露了过多的内部结构，则可以使用FACTORY进行封装。

我们仍然需要一种更加抽象且不与其他对象发生耦合的构造机制。这就是FACTORY，它是一种负责创建其他对象的程序元素。

FACTORY METHOD（工厂方法）、ABSTRACT FACTORY（抽象工厂）和BUILDER（构建器）

认知超载，cognitive overload，认知负荷理论（cognitive load theory）中的一个术语。问题解决和学习过程中的各种认知加工活动均需消耗认知资源，若所有活动所需的资源总量超过个体拥有的资源总量，就会引起资源的分配不足，从而影响个体学习或问题解决的效率，这种情况被称为认知超载。

持续重构让事物逐步变得有序。代码和模型的每一次精化都让开发人员有了更加清晰的认识。这使得理解上的突破成为可能。之后，一系列快速的改变得到了更符合用户需要并更加切合实际的模型。其功能性及说明性急速增强，而复杂性却随之消失。

我们可以对类和方法进行分解，这样可以更好地重用它们，但这些小部分的行为又变得很难跟踪。如果软件没有一个条理分明的设计，那么开发人员不仅不愿意仔细地分析代码，他们更不愿意修改代码，因为修改代码会产生问题——要么加重了代码的混乱状态，要么由于某种未预料到的依赖而破坏了某些东西。在任何一种系统中（除非是一些非常小的系统），这种不稳定性使我们很难开发出丰富的功能，而且限制了重构和迭代式的精化。

创建一个隔离层，以便根据客户自己的领域模型来为客户提供相关功能。这个层通过另一个系统现有接口与其进行对话，而只需对那个系统作出很少的修改，甚至无需修改。在内部,这个层在两个模型之间进行必要的双向转换。

定义一个协议，把你的子系统作为一组SERVICE供其他系统访问。开放这个协议，以便所有需要与你的子系统集成的人都可以使用它。当有新的集成需求时，就增强并扩展这个协议，但个别团队的特殊需求除外。满足这种特殊需求的方法是使用一次性的转换器来扩充协议，以便使共享协议简单且内聚。

在设计大型系统时，有非常多的组成部分——它们都很复杂而且对开发的成功也至关重要，但这导致真正的业务资产——领域模型最为精华的部分——被掩盖和忽略了。