DDD（领域驱动设计）概述

定义

• 领域驱动设计是一种处理高度复杂域的设计方法，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在演进时任然保持敏捷。

概述

• DDD不是语言，不是框架，不是架构，而是一种方法论，它可以分离业务复杂度和技术复杂度，DDD也并不是一个新的事物，它是面向对象的拔高，最终目标还是高内聚、低耦合。
• DDD的整个过程大概是这样的，开发团队和领域专家一起通过 通用语言 去理解和消化领域知识，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型，再重复以上步骤，周而复始构建出一套符合当前领域的模型。

核心概念

通用语言

• 通用语言是一种沟通工具，在开发团队内部，开发团队与领域专家之间使用。它包含了自然语言、文档和图表（不一定是标准的UML图，只要能表达出领域知识的都可以）等内容。对通用语言中名词，动词的使用需要认真考量，这些名词和动词会指导后面模型的命名。
• 通用语言以领域专家的语言为基础，进一步进行规范化，或简化，或抽象，使得该语言既正确又容易理解，且不脱离领域专家的语言范畴。
• 在限界上下文之内的每种领域术语，词组或句子。它们在同一个上下文中具有唯一确定的含义，在限界上下文之外，它们可能表达不同的含义。

特征

• 必须在领域模型中表达。
• 统一了项目团队的员工表达语言。
• 消除了领域专家的不准确和矛盾。
• 不是领域专家强加的业务语言。
• 不是行业中使用的语言。
• 随着时间的推移而发展变化，它并不是完全在一次或几次会议中定义的，而是逐渐演变的。

领域

• 领域指的是一个特定的业务范围，大家在这个业务域范围内开展工作。一个系统可能由一个领域或者多个领域组成。在认识领域时一定要注意所指的业务域，行业、项目或系统都不能准确地表达领域所指的业务域。
• 领域用于确定边界，DDD会按规则细分业务领域，细分到一定程度，DDD会将问题范围限定在特定边界，在该边界内建立领域模型，进而用代码实现该领域模型，解决相应业务问题。
• 领域的核心思想是将问题域逐级细分，降低业务理解和系统实现的复杂度。

子域

• 子域是对领域从业务需求方面进行的拆分。由于领域的概念通常都过大，所以我们一般都会将其进行拆分，诸如核心域，通用域，支撑域。一般来讲核心域就是整个产品的业务价值所在。或者按照业务来拆分，诸如订单子域，产品子域，物流子域等。
• 通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。
• 商业模式和战略方向决定公司在划分核心域、通用域和支撑域。不同的商业模式及战略方向决定划分也不相同。在公司领域细分、建立领域模型和系统建设时，要结合公司战略重点和商业模式，找到核心域，且重点关注核心域

核心域

• 业务成功的核心竞争力，决定产品和公司核心竞争力的子域是核心域。

通用域

• 不是核心，但被整个业务系统所使用 （可以直接购买的）。
• 没有太多个性化诉求，同时被多个子域使用的通用功能子域是通用域。比如认证、权限等，这类应用很容易买到，没有企业特点限制，无需太多定制化。

支撑域

• 不是核心，不被整个系统使用，完成业务的必要能力（可以外包出去的）。
• 既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又是必需的支撑域。支撑域具有企业特性，但不具通用性，例如数据代码类的数据字典等系统。

限界上下文

• 限界上下文是一个边界，领域模型便存在在这个边界之内。当模型被一个显示的边界所包围时，其中每个概念的含义便是确定的了。因此，限界上下文主要是一个语义上的边界。
• 对于通用语言，限界上下文是语言的边界，对于领域模型，限界上下文是模型的边界，二者对应于问题空间（Problem Space）的界定。 对于系统的架构，限界上下文还确定了应用边界和技术边界，进而帮助我们确定整个系统及各个限界上下文的解决方案。
• 原则上，一个上下文就对应一个子域。但这并不是绝对的，限界上下文的目的是为了更加明确领域模型的职责和范围，是从“解决方案空间”来考虑问题的。通常来说，一个限界上下文可以是一个微服务，或者一个模块。

划分原则

• 概念相同，含义不同：如果一个模型在一个上下文里面有歧义，那有歧义的地方就是边界所在，应该把它们拆到不同的限界上下文中。
• 外部系统：有时候系统需要同外部系统打交道，这个时候可以把与外部系统打交道的那部分拆分出去以实现更好的扩展性。这样一旦外部系统发生了变化，就不会影响到我们的核心业务逻辑。
• 组织扩展：尽量不要两个团队一起在一个限界上下文里面开发，因为这样可能会存在沟通不顺畅、集成困难等问题。