只有更好地解决用户真正关心的领域问题，软件开发人员才能获得职业生涯的长青。

更新历史

• 2022.12.17：完成初稿

读后感

很早之前就听过 DDD 的大名，但直到今天才通过精简版来学习了一下，感觉有点晚，但又感觉不太晚。可能现在看刚好能看懂，也有实践的机会，不然实际上等于白学。It’s never too late to learn!

读书笔记

• DDD 并不是突然冒出来的，其实是 30 年来业务软件开发实践经验的结晶
• 代码的质量如果不加以控制，就一定会迅速腐烂变质
• 概念完整性就相当于热力学第三定律中的熵，是衡量软件项目混乱程度的重要指标
• 对于业务开发人员而言，衡量一种技术好坏的最终标准，应该是这种技术是否有助于开发人员专注于研究领域问题。只有更好地解决用户真正关心的领域问题，软件开发人员才能获得职业生涯的长青

何为领域驱动设计

软件开发通常被用于将真实世界中已经存在的流程自动化，或者为真实的业务问题提供解决方案。需要自动化的业务流程或者真实世界的问题，就是软件的领域。

为了创建一个好软件，你必须知道这个软件究竟是什么。怎样才能让软件和领域合写相处呢？最佳方式是让软件成为领域的一个映射。软件需要包含领域里最重要的概念和元素，并精确实现它们之间的关系。也就是说，软件需要对领域进行建模。

通过与领域专家的交谈，软件设计人员的分析型思维(analytical mind)会帮助他们挖掘出领域中的一些关键概念，并且帮助构建出可用于将来讨论中的结构。因为软件的最终目的是去解决真实领域中的业务问题，所以它必须和领域完美结合。

通用语言

在讨论模型和定义模型时，我们确实需要讲同一种语言。领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型时软件满足领域的共同点，它很适合作为这种通用语言的构造基础。

由软件架构师、开发人员和领域专家组成的设计团队，需要有一种语言来统一它们的行动，以帮助他们创建一个模型，并使用代码来表达模型。

模型驱动设计

一种更好的方法是将领域建模和设计紧密关联起来。模型在构建时就考虑到软件实现和设计。开发人员应该被加入到建模的过程中来。

模式间关系总图

分层架构

• 用户界面：负责向用户展现信息以及解释用户命令
• 应用层：很薄的一层，用来协调应用的活动。它不包含业务逻辑。它也不保留业务对象的状态，但它保留有应用任务的进度状态
• 领域层：包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态。对业务对象和它们的状态的持久化被委托给了基础设施层
• 基础设施层：其他层的支撑库。他提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支持库等作用。

服务

服务的 3 个特征：

1. 服务执行的操作代表了一个领域概念，这个领域概念无法自然地隶属于一个实体或者值对象
2. 被执行的操作涉及到领域中的其他的对象
3. 操作是无状态的

面向深层理解的重构

模型的复杂性和模型的可变性，使我们不可能按照机械的方式进行建模。一个优秀的模型产生于深层的思考哦、理解、经验和天分。

除非使用迭代的重构过程，加上领域专家和开发人员一起密切关注对领域的学习，否则一个复杂成熟的领域模型是很难开发出来的。

保持模型的一致性

从一个良好的模型开始，发展到后来却变成了一个不一致的模型，这种情况很容易出现。当模型的设计在局部独立进化时，我们就面临着市区模型完整性的可能。努力为整个企业项目维护一个大的统一模型，以获得模型完整性，这个办法也不会有什么作用。

解决方案并非显而易见：不是试图保持一个迟早要四分五裂的大模型，我们应该做的是有意识地将大模型分解成多个较小的模型。只要遵守它们所绑定的七月，良好整合的小模型能够独立进化。每个模型都应该有一个清晰的边界，模型之间的关系也应该被精确地定义。

在设计一个大型系统时，有那么多分布式组件，所有的都是那么复杂而且绝对必须不出差错，而领域模型的基本内容，也就是真正的业务资产(business asset)，却变得模糊不清和不受重视。

对模型做提炼，找到核心域（也就是二八原则），提供一种手段将核心域与支持模型和代码(mass of supporting model and code)。对最优价值和专业的概念加以强调。尽量使核心域小一些。

专访 Eric Evans

要谨记 DDD 主要是由团队来完成的事情，所以你也许要成为一个布道者！另外还要注意：

1. 亲自动手，建模者需要写代码
2. 专注于具体场景。抽象思维需要落地于具体案例
3. 不要试图对任何事情都应用 DDD。画一张上下文映射，然后决定在哪里需要努力应用 DDD，在哪里不需要。不要担心边界之外的事情
4. 进行大量的常识，期望能产生大量错误。模型是一个创造性的过程。