初识DDD-理解基本概念

0 概述

2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。领域驱动设计这一理念迅速被行业采纳，时至今日仍是绝大多数人进行业务建模的首要方法。随着Martin Fowler 提出微服务架构，DDD也迎来了新的时代。
DDD概念比较多，像：领域、子域、核心域、通用域、支撑域、限界上下文、聚合、聚合根、实体、值对象等等，非常多。这些名词，都是关键概念，但它们实在有些晦涩难懂，可能导致你还没开始实践 DDD 就打起了退堂鼓。因此，本文将结合自己工作理解对DDD相关概念总结。

1 基本概念

1.1 究竟什么是DDD

首先DDD 不是架构也不是框架，而是一种架构设计的方法论。其次我们都知道软件开发的核心难度在于处理隐藏在业务知识中的复杂度，那么模型就是对于这种复杂的简化和精练；DDD就是一种模型驱动设计方法，通过领域模型捕获领域知识，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。
模型在领域驱动设计中，其实主要有三个用途：1）通过模型反映软件实现的结构 2）以模型为基础形成团队的统一语言（Ubiquitous Language）3）把模型作为精粹的知识，以用于传递。样做的好处是显而易见的：理解了模型，你就会大致理解代码的结构；在讨论需求的时候，研发人员可以很容易明白需要改动的代码，并对风险与进度有更好的评估；模型比代码更简洁，毕竟模型是抽象出来的，因而有更低的传递成本。

1.2 如何理解领域和子域？

维基百科给出的定义：
A sphere of knowledge，influence, or activity. The subject area to which the user applies a program is the domain of the software.
一个特定范围的知识、影响或者活动。这个主题域应⽤用到程序上就是这个软件系统的领域。
百度百科给出定义：具体指一种特定的范围或区域。
可以看出两个定义都强调了范围，范围即边界，这也是DDD在设计中不断强调边界的原因。既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围越大；比如说电子商务领域，就是任何通过某种电子媒介而使得买卖双方完成在线交易的过程中需要解决所有问题的总合；电商领域是一个比较大的领域，通常的做法就是将问题一步一步地细分&拆解，再针对细分出来的子问题域，逐个深入研究，探索和建立所有的子问题域的知识体系。如下图将电商领域逐步拆解为买家、卖家、商品、库存、营销、履约、交易等子问题域，当然子问题域也可以进一步拆分为子子问题域，如交易可以拆分为订单域和支付域。

领域细分过程，如下图所示。

1.3 如何理解核心域、通用域和支撑域？

领域在不断细分&拆解不同子域，这些子域可以根据自身的重要性和功能属性，可以分为三大类，即：核心域、通用域、和支撑域，如下图所示，其中核心域是重心，支撑域和通用域为了支撑核心域的。值得说明是核心域只是一类统称，核心域可以包含多个功能子域。
核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。当然我们不能说支撑子域和通用子域是不重要的，它们也是重要的，只是我们对它们的要求并不像核心域那么高。

1.4 如何理解通用语言和限界上下文

在DDD领域建模和系统建设的过程中，有很多的参与者，包括领域专家、产品经理、项目经理、架构师、设计师等。对同样的领域知识，不同的参与角色可能会有不同理解，那大家交流起来就会有障碍；为了解决了这个问题，DDD提出了通用语言和限界上下文。这两者相辅相成，通用语言定义上下文含义，限界上下文则定义领域边界；在一个特定的限界上下文中，通过统一语言定义或者描述上下文的含义，并确保它的准确性和清晰性。
统一语言是基于领域模型的共同语言统一语言（Ubiquitous Language）是一种业务方（泛指一切非最终软件实现者）与技术方共同使用的共同语言（Common Language），业务方与技术方通过共同语言描述业务规则与需求变动。共同语言也有很多种形式。比如，用户画像（User Persona）与相关的用户旅程（User Journey），就能从流程角度有效地构成共同语言。
DDD强调模型驱动设计，为啥不直接使用模型做为了统一语言呢？主要因为1）模型将业务维度隐藏了，对业务方显得不够直观。业务方习惯从业务维度，如流程、交互、功能、规则等维度出发去描述软件系统，这些也是业务方主要感知软件系统的途径；模型则更偏重于数据角度，描述了在不同的业务维度下，数据将做如何改变，以及如何支撑对应的计算和统计。2）模型是从已知需求中总结提炼的知识，这就意味着模型无法表达未知需求中尚未提炼的知识。

我们可以将限界上下文拆解为两个词：限界和上下文。限界就是领域的边界，而上下文则是语义环境，表现为业务流程的场景片段，整个业务流程由多个时序活动节点组成，随着流程进行不同的活动需要不同角色或系统参与，并导致上下文因为为某个活动发节点的执行发生了切换，形成场景的边界&领域边界。以我的一天为例：早上乘坐地铁到公司去上班搬砖，晚上下班打出租车回家。无论我是做做地铁还是晚上打车，虽然我需要做的事情不同，但是我的身份都是是乘客。我做在地铁上是否就一定代表我属于出行上下文呢？不一定，我做在地铁上可能拿出电脑处理工作问题，这个时候上下文就切换到搬砖上下文了。
在特定领域限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。综合一下，我认为限界上下文的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

2 领域模型基本概念

2.1 什么是实体和值对象？

2.2 什么是聚合和聚合根

参考文献
[1] 极客时间-DDD实战课，欧创新
[2] 极客时间-如何落地业务建模，徐昊
[3] 解构领域驱动设计，张逸