谈DDD领域驱动设计和建模

本文谈下领域驱动设计方面的内容，其中部分内容来源于《领域驱动设计:软件核心复杂性应对之道》书籍的读书笔记整理。

我前面谈了很多关于中台，SOA和微服务的文章，实际上你可以看到中台层对外和对前台提供的服务更多就应该是粗粒度的领域服务能力，如果中台最终只提供书籍对象的CRUD类API接口服务，那么根本就谈不上中台的共性业务服务能力下沉。

领域驱动设计概述

什么是领域驱动设计（DDD）

2004年著名建模专家Eric Evans发表了他最具影响力的书籍：《Domain-Driven Design –Tackling Complexity in the Heart of Software》（中文译名：领域驱动设计—软件核心复杂性应对之道），书中提出了“领域驱动设计（简称 DDD）”的概念。

领域驱动设计事实上是针对OOAD的一个扩展和延伸，DDD基于面向对象分析与设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。

领域模型是领域驱动的核心。采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对小的领域对象(类)组成，这些类具备自己的状态和行为，每个类是相对完整的独立体，并与现实领域的业务对象映射。

领域模型就是由这样许多的细粒度的类组成。基于领域驱动的设计，保证了系统的可维护性、扩展性和复用性，在处理复杂业务逻辑方面有着先天的优势。

领域驱动设计的特点

领域驱动的核心应用场景就是解决复杂业务的设计问题，其特点与这一核心主题息息相关：

• 分层架构与职责划分：领域驱动设计很好的遵循了关注点分离的原则，提出了成熟、清晰的分层架构。同时对领域对象进行了明确的策略和职责划分，让领域对象和现实世界中的业务形成良好的映射关系，为领域专家与开发人员搭建了沟通的桥梁。
• 复用：在领域驱动设计中，领域对象是核心，每个领域对象都是一个相对完整的内聚的业务对象描述，所以可以形成直接的复用。同时设计过程是基于领域对象而不是基于数据库的Schema，所以整个设计也是可以复用的。

领域驱动设计的分层架构

下面我们简单介绍一下领域驱动设计的分层架构和构成要素，这部分内容在Eric Evans的书中有非常详尽的描述，想要详细了解的，最好去读原版书籍。

下面这张图是该书中著名的分层架构图，如下：

整个架构分为四层，其核心就是领域层（Domain），具体描述如下：

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

对于领域在这里我更愿意将其理解为业务领域，领域的表现是一系列存在相关关联和依赖关系的业务实体对象表现出现的业务行为的一个合集。

传统的用例驱动往往我们会先分析会有哪些业务行为和业务操作，再来分析这些行为操作的承载对象，如RUP中的实体类控制类等。领域驱动的方法则可能是尽快先找出核心的业务实体对象，再通过交互分析来分析对象应该展现出来的行为。

在解耦的层面我们看到两个层面的解耦：

第一个层面是业务操作和业务实体的解耦，这也是传统的SOA的一个思想，在领域建模里面可以看到分解为业务服务，实体对象和值对象等。

第二个层面则是应用功能，服务能力，基础设施三层的解耦，在领域驱动设计的分层架构中则将其分解为了应用层，领域层，基础设施层。基础设施层提供资源层和持久化的能力，领域层提供业务服务能力，而应用层仅仅处理能力的协同，状态保存，服务的编排问题等。

领域驱动设计中领域层的构建可以是整个系统构建的核心，通过领域层的构建再拓展到持久化层和界面展现层。领域模型完全基于面向对象思路构建，因此完全可以兼顾底层是关系型数据库还是NoSQL数据库来持久化。而且领域模型的持久化好像专门就是为适合NoSQL数据库而设计。对于界面展现层相同的道理，领域层只是提供和暴露业务服务，具体业务服务如何交互，协同和展现并不是关键。

一个完整的领域层应该包括了实体对象，值对象，主域模型类，业务服务类几个关键的类。

实体对象有唯一的标识符，需要持久化，对应现实中的业务对象，而值对象无唯一标识符，仅仅关注它拥有的一组属性。实体对象本身会表现出对应到行为，而值对象仅仅是属性的结合。在多个实体对象上层可能还要构建主域层对象，程度跨多个实体对象的操作组合。而对于业务服务仅仅是能力通过接口方式的暴露。一方面是实现应用层到领域层的协同，一方面是实现多个domain主域间的协同。

对于领域层，在大型系统构建过程中可以是首先进行全局的领域层建模再划分为多个domain域，形成业务组件或模块。也可以首先进行业务主体域的划分，然后再分解下去后识别每个业务域里面的实体对象和表现行为。组件划分思路需要引入到大型领域层的构建。即领域层也会组件化和模块化。业务服务即需要考虑模块内，也需要考虑模块间协同。在这里可以看到是领域层本身进行模块化后引入的，对业务服务的能力进行了扩展。

领域驱动设计让我们在分析