领域驱动设计(1) DDD的一些基础概念

• 什么是DDD

• DDD的特点

  • 战略设计、战术设计

  • DDD在微服务中解决的问题

  • DDD的好处与局限

• 领域

  • 领域、子域

  • 核心域、通用域、支撑域

• 通用语言、限界上下文

  • 通用语言

  • 限界上下文

• 实体、值对象

  • 实体

  • 值对象

• 聚合和聚合根

  • 聚合

  • 聚合根

  • 如何设计聚合

  • 聚合的设计原则

什么是DDD

看了一些DDD的介绍、教程，这些教程无一例外都会讲一个关于美好邂逅的故事，故事的情节大概是这样的：DDD是2004年出现的，但一直不温不火，直到十来年后出现了微服务，大家在落地微服务的时候遇到了各种各样的问题，其中就有一个很让人头疼的：“微服务到底要多微”？，大家总说纷纭，直到有人把DDD的方法论应用到微服务的拆分，两者一拍即合，过上了幸福的生活…
我对微服务和DDD都没有太多的了解与实践，不敢妄加评论，但上面的故事情节总感觉有种童话故事中王子遇青蛙、或者武侠小说中少年偶遇隐者学成神功的故事一般，带着巧合、虚幻的味道。也许看似巧合的背后，有更深层次的原因。也许看似美好的结合背后，也不过是解决一个问题、又带来一堆新问题的尴尬。
真实情况到底是什么样，个人目前无法做出判断，且待学完DDD再说。

DDD的特点

《DDD实战课》的作者欧创新认为：

DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

即主要在于两点：确定业务边界、保证模型与代码一致。但按照之前徐昊在《如何落地业务建模》中的观点，应该再加上“统一语言”一项，它也是DDD的核心，统一语言作为业务人员和技术人员统一的交流语言，而且与模型关联，是DDD能够成功运转的关键。
以下是《如何落地业务建模》的内容摘录：

Eric 倡导的领域驱动设计是一种模型驱动的设计方法：通过领域模型（Domain Model）捕捉领域知识，使用领域模型构造更易维护的软件。

模型在领域驱动设计中，其实主要有三个用途：
1.通过模型反映软件实现（Implementation）的结构；
2.以模型为基础形成团队的统一语言（Ubiquitous Language）；
3.把模型作为精粹的知识，以用于传递。

在 DDD 中，Eric Evans 提倡了一种叫做知识消化（Knowledge Crunching）的方法帮助我们去提炼领域模型：
1.关联模型与软件实现；
2.基于模型提取统一语言；
3.开发富含知识的模型；
4.精炼模型；
5.头脑风暴与试验。

战略设计、战术设计

整体来看，DDD分为战略设计、战术设计两大部分。
战略设计从业务视角出发，建立领域模型、划分领域边界、建立通用语言的限界上下文；
战术设计则关注将模型转化为软件实现的过程&#