DDD领域驱动设计与实践

1、 领域建模与设计的关系

优秀的软件系统与好的软件设计息息相关，但最关键的还是在于对需求的理解。如果不能正确的理解软件需求，那么再好的设计也不能设计出好的软件。正确的做事情固然重要，更重要的是要做正确的事。然而，需求到设计存在巨大的鸿沟，因为需求是站在业务角度来考虑，而设计往往会站在实现角度。领域建模就是为这二者搭建一个沟通与转换的桥梁。

2、 本部分对比了用例驱动设计、ICONIX 以及领域驱动设计，说明它们之间的关系、运用场景和区别。

内容包括：

问题域

核心领域宇子领域

解决方案域

第二单元：领域驱动设计的战略设计

1、通用语言（Ubiquitous Language）

为了更好的理解需求，我们需要与领域专家一起梳理目标领域的通用语言，从而就领域术语达成一致，并有利于领域建模。本部分将给出实例来说明通用语言对模型以及代码的影响。

内容包括：

获得通用语言的方法

通用语言对编码的影响

2、限界上下文（Bounded Context）若要进行领域建模，并将业务需求逐步演化为架构设计，则需要引入DDD（领域驱动设计）的战略设计作为指导。场景图与限界上下文可以很好地结合，帮助架构师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想识别出整个系统的业务逻辑边界与物理边界。本部分同时还讨论了诸多设计原则在 Bounded Context 中的运用，探讨了 Bounded Context 的本质思想，强调 Bounded Context 的边界，进而与微服务架构结合起来，即 Bounded Context 的设计其实就是微

服务的设计。

 内容包括：

Bounded Context 意义

识别 Bounded Context

议题：Bounded Context 的边界

3、场景驱动

场景驱动设计的核心在于识别场景，它需要设计者结合具体的业务场景，分析业务流程，以此驱动出用例；再以用例驱动对业务逻辑的建模。场景驱动设计的核心模型为 6W 模型，即 Who，Why，When，What，Where 与hoW。它将对应职责模型的业务价值、业务功能与业务实现，并从角色的角度思考对象之间的协作以及设计边界。

4、通过用例识别 Bounded Context

通过利用传统的用例方法来帮助我们驱动出领域的限界上下文。

可视化演练：识别 EAS 的限界上下文

5、Bounded Context 与微服务之间的关系通过 Bounded Context，可以让 DDD 与微服务之间建立一种对应关系，即将 BC 视为独立进化部署的微服务边界。本部分将通过实例深入探讨 BC 的边界问题，并拓宽讲解微服务的设计。

6、上下文映射图 (Context Map)本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式，这其中包括防腐层，开放服务调用等。利用上下文映射图，有助于识别上下文之间的关系，思考处于上下文内领域模型之间的通信方式，从而帮助架构师驱动出最终的应用逻辑架构。

内容包括：

团队的组织模式

集成模式

Context Map 案例分析

7、可视化演练：EAS 的应用逻辑架构

第三单元：领域驱动设计的架构设计

1、分层架构 (Layered Architecture)分层架构模式是应用最为广泛的架构模式，它根据关注点分离的架构原则，针对表现层、领域层和基础设施层进行层次分离。本次培训将以全新视角审视分层架构，针对大型软件系统分析该如何进行分层架构设计。

内容包括：

DDD 分层架构模式

Clean Architecture 思想

依赖注入与贫血模型

案例分析：网上银行的分层架构，根据最基本的业务流程对系统进行关注点分离，绘制系统的分层架构，并通过时序图展现各层之间的协作。

2、六边形架构 (Hexagonal Architecture)虽然分层架构仍然是运用最为广泛的架构模式，同时更是诸多架构模式的基础，但它已不足以描述越来越复杂的分布式系统架构。由 Cockburn 提出的六边形架构（Hexagonal Architecture）是一种具有对称性特征的架构风格。在这种架构中，不同的客户通过“平等”的方式与系统交互。该架构中存在两个区域，分别是“外部区域”和“内部区域”。这种界定了明确内外边界的架构风格，更有利于架构师实现关注点分离，并将关注重心放在适配器与通信端口上。

演练：六边形架构的通信边界

3、CQRS

CQRS 风格，即命令查询职责分离（Command Query Responsibility Segregation），它结合了消息处理、事件处理的架构风格，是对多种设计模式的综合运用，适用于处理读写比例高，需要支持可伸缩性的大型系统。

4、事件驱动架构 (Event-Driven Architecture)

事件驱动架构（Event-Driven Architecture，EDA）是一种用于处理事件生成、发现和处理等任务的软件架构。事件往往对应于软件系统的状态机，状态的迁移就是用事件来触发的。因而，事件能够很好地体现这样的业务模型。同时，基于事件的软件架构可以帮助我们更好地建立松散耦合的模块化架构。

第四单元：领域驱动设计的战术设计

1、领域模型

通过限界上下文，可以帮助我们分析系统的领域模型，包括系统的核心领域与子领域。确定系统的核心领域与子领域可以帮助架构师合理分配资源（包括时间资源与人力资源）。而对子领域的进一步识别，可以帮助架构师更好地识别可重用资源，包括可重用的功能模块，确定技术栈，决定构建还是购买的架构战略。

内容包括：

DDD 核心概念和要素要素

领域建模的演进

2、四色建模法

首先以满足管理和运营的需要为前提，寻找需要追溯的事件。根据这些需要追溯，寻找足迹以及相应的时标性对象。寻找时标对象周围的人／事／物。从中抽象角色，把一些信息用描述对象补足。

案例分析：配送管理系统的四色建模

3、实体（Entity）与值对象（Value Object）

这两个概念都是领域对象的体现，二者的主要区别在于对“标识”的运用。本部分的内容深入展开对实体标识的讨论，揭示实体的本质特征，挖掘实体

的关键行为。通过识别角色与职责对实现进行分析。

本部分内容还将通过深入讲解值对象的特征帮助我们分辨值对象与实体，使得我们可以在领域驱动设计中有效地运用实体与值对象。本部分内容还包括持久化值对象，以及领域驱动设计与 ORM 之间的关系。

内容包括：

实体的标识别

避免贫血模型

角色、职责与协作

领域建模与数据建模

4、领域服务 (Domain Service)

通过讲解什么是领域服务，什么不是领域服务理清领域服务的概念，并讲解如何建模领域服务。讨论领域服务和面向接口设计思想。

内容包括：

何时建模为服务

识别建模的坏味道

5、领域事件 (Domain Event)

事件驱动架构的主要对象即为领域事件，我们要分清在何时以及为什么要使用领域事件，并对领域事件进行建模。通过讲解发布者-订阅者模式讲解如何在领域模型和限界上下文中发布领域事件。同时，针对事件进行存储的 EventSource 也与 CQRS 架构风格直接相关。

内容包括：

事件的本质

事件带来的价值

演练：寻找领域事件

6、聚合 (Aggregation)

聚合是领域驱动设计最为重要的领域概念。本部分内容将深入探讨聚合的设计原则，并辨别在聚合设计中可能出现的坏味道，并提出针对性的解决方案。这些原则和方案包括：在一致性边界之内建模真正的不变量，设计小的聚合，通过唯一标识引用其他聚合，在边界外满足最终一致性。

内容包括：

聚合维护多个实体、值对象的边界

案例研究

设计聚合的原则

7、工厂(Factory)和资源库(Repository)

工厂和资源库都是管理领域对象（实体、值对象和服务）生命周期的对象。工厂主要针对内存中对象从无到有的创建过程，与设计模式的工厂模式基本相似。

资源库则分为面向集合的资源库与面向持久化的资源库。本部分内容将重点讲解与资源库直接相关的技术细节，包括如何选择资源库的方式，如何针对聚合持久化资源库，如何管理事务，以及分辨资源库与数据访问对象（DAO）之间的异同。

8、应用层(Application Layer)设计

作为为 UI 提供的应用服务，其目的在于管理和协调领域对象，并为领域对象提供横切关注点的内容。好的应用服务设计不应该承担任何与领域逻辑有关的职责。应用层是架构层面的外观与适配器模式的体现。它可以提高软件系统架构的可用性与简单性，也能够更好地与面向服务架构或 RESTful 架构风格结合。

9、时序图

根据事先识别的 Use Case，为其绘制时序图，动态地寻找 Application Service 到各种领域对象之间的协作，以帮助我们寻找到遗漏的领域对象与设计对象。

第五单元：DDD 专题讨论

专题一：贫血模型

Transaction Script 与 Domain Model 之争贫血模型与充血模型之争Service 废存的争论

专题二：DCI

DCI 是领域驱动设计的一个分支，更加关注系统的行为，从而提高代码的可读性。该范式将 Data Model（data）从 Use Cases(context)以及对象扮演的 Role（Interaction)中分离出来。

第六单元：DDD 实战演练