一、DDD背景
2003 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。
但 DDD 提出后在软件开发领域一直都是“雷声大，雨点小”！直到 Martin Fowler 提出微服务架构，DDD 才真正迎来了自己的时代。
大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的（Action、Service、Dao），在这种分层理论中，我们基本没有啥机会使用那些所谓的“行为型”的设计模式，这里的核心原因，就是J2EE经典分层的开发方式是“贫血模型”。
二、什么是DDD
如下图，传统的敏捷开发模式，我们更多的使用数据驱动设计的思想，按照功能模块来，拆分成一个个的小模块，每个模块要实现什么功能，需要什么样的数据，然后就通过ER数据建模，建库建表后开干了，这样会导致N个系统中重复的功能会反复建设，Service层编写了繁杂的业务逻辑，耦合度极高，经常牵一发而动全身。
而DDD是指需求输入的时候，从领域开始聊起，比如教育是一个领域，先从校长聊起，然后聊到他的关联实体老师，学生，考试等等，这些实体之间的关联关系是什么，他们各自都会有哪些行为方法和业务逻辑。聊清楚后进行实体的建模，聚合实体的行为形成一个个领域服务，比如学生+老师的实体组合成了上课这一领域服务，之后再对领域服务进行编排，组成核心的可复用的业务逻辑。
再之后就是经过领域模型划分微服务界限，映射模型和微服务代码后进行开发，DDD就是以领域为入口，来解决产品设计，研发的思想。
DDD通过领域建模，编排核心业务逻辑后映射到微服务开发的过程，有利于构建出企业可复用的核心能力，减少重复的IT建设，同时开发者可以根据模型和微服务代码设计的对应关系，快速清晰的完成开发。同时后面博文会讲到DDD严格的分层结构设计，能够帮助构建一个“低耦合，高内聚”，可演进的系统。
三、DDD的战略和战术
DDD不是架构，而是架构设计思想，演进的方法论，旨在聚焦业务领域模型来控制业务的复杂性，同时分离技术和业务耦合的复杂性。
DDD包括战略设计和战术设计两部分
战略设计：从业务视角出发，业务领域专家和技术专家通过事件风暴，建立共同的语言，构建领域模型，同时划分好领域的限界上下文，并以限界上下文作为微服务拆分和设计的边界，做业务核心逻辑的编排，从而在业务中台构建可复用的核心能力。
战术设计：从技术角度出发，聚焦于领域模型如何映射到微服务代码开发的实现上。限界上下文和领域模型作为输入，从领域模型中抽象出来聚合，聚合根，实体，值对象，领域服务，领域事件，应用服务编排，仓储等，以表格或其他形式一一对照模型去设计代码，并最终结合分布式缓存，消息最终一致性等基础支撑实现落地。
DDD按照一定规则将业务领域细分，细分到一定程度后，DDD将要解决的问题限定在特定范围内，这个过程中，可以将领域划分为子域，子域还可以继续划分为子子域，直到细分的程度，可以明确的区分不同业务领域，又不至于过度拆分，并适合微服务团队实施落地。DDD通常将划分后的子域区分为核心子域，支撑子域和通用子域。比如电商领域的子域划分
DDD这种子域的划分方法，可以帮助企业IT建设过程中确定中台的领域边界。
四、DDD、中台和微服务如何协同工作
业务中台的形成，实际也是业务领域不断细分，演进和能力沉淀的过程，所以中台是DDD战略设计的落地，DDD最擅长的就是领域建模。
微服务的架构设计，参照着建模后的领域模型和限界上下文，作为微服务拆分的边界和依据，然后微服务与领域里的一个个子域互相映射，完成代码开发，是DDD的战术落地。
本文先从粗粒度来描述DDD战略设计和战术设计的实现，细粒度的实现待后面更新完子域，限界上下文，实体和值对象，聚合和聚合根，仓储模式，领域事件，分层架构等等后自然了解。下面看领域建模和中台建设，如何映射与关联。
通用中台对应的DDD的通用子域和支撑子域，实现企业可复用的通用业务能力，核心中台对应DDD的核心子域，这部分是DDD战略设计落地的产物。
领域模型和限界上下文，则与中台建设中的微服务对应，DDD建立的领域模型可以作为微服务划分的依据，完成微服务的拆分和开发，这部分是DDD战术设计落地的产物。
中台业务抽象就是领域建模的过程，系统抽象就是微服务设计过程，中台业务建模和落地，大致分如下几步
1、选取主领域模型，按照业务流程节点，将业务划分为业务中台（多个核心子域），将通用的功能和支撑划分为通用中台（通用域，支撑域），较大范围的业务领域，需要再逐级划分为大小合适的领域再构建领域模型
2、选取逻辑相对完整的领域模型作为主领域模型（如用户这个领域对象，常常分散到不同的领域模型中）以主领域为基准，扫描其他中台领域模型，检查是否存在功能重叠的模型，合并到主领域模型，完成领域模型的提炼
3、选择其他主领域模型重复第二步，直到完成所有领域模型的比对
4、将领域模型作为微服务设计的输入，完成微服务拆分和设计
