“尺有所短，寸有所长；不忘初心，方得始终。
前言
DDD是软件设计的一种方式，在理解DDD之前，先来看看软件设计类别，一共分为三类，分别是DL驱动开发、数据驱动设计以及DDD驱动设计。
DL驱动开发
DeadLine驱动开发，给定一个截止日期，只要在这个DL之前完成即可。
“
DL驱动开发只追求短期的业务目标，不关注程序设计，缺乏过程管理，程序难以扩展维护。
数据驱动设计
针对需求进行数据库表设计，再通过数据流串联对应的业务流程，是最常用的软件设计方式，基本可以应对大多数的应用服务场景。
DDD领域驱动设计
随着系统越来越庞大，传统的软件设计方式已经不能满足我们应对复杂系统的设计。而DDD由业务为导向，通过领域建模限定边界，提供了应对大型复杂系统与业务的方法论。
一、什么是DDD
DDD即领域驱动设计（Domain Driven Design）。在2004年建模专家Eric Evans在《Domain-Driven Design –Tackling Complexity in the Heart of Software》（领域驱动设计：软件核心复杂性应对之道）已经提出来相应的概念。
DDD不是一种架构形式，它是一种架构设计的指导思想，是一种应对复杂域问题的方法论。
DDD将一个软件系统的核心业务功能集中在一个核心域里面，其中包含了实体、值对象、领域服务、资源库和聚合等概念。在此基础上，DDD提出了一套完整的支撑这样的核心领域的基础设施。
中台、微服务与DDD
微服务架构能让系统的开发与运维管理变得简单高效，还能提高系统的可用性。但是微服务也有其不足之处，在微服务拆分时，拆分的粒度总是不好把控，拆分的过细，会导致服务增多，增加维护和运维成本。拆分粒度粗，随着业务的增长，单个服务也会变得臃肿，丧失了微服务的初衷。而DDD则可以有效帮助我们确定服务边界，DDD从业务出发，确定各个领域边界，划定职责。
DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。DDD 强调领域模型和微服务设计的一体性，微服务设计依托于领域模型。
DDD 关注：从业务视角划分领域边界，构建通用语言，通过业务抽象建立领域模型，维持业务和代码的一致性。
微服务关注：侧重于运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。
总结：中台本质是领域模型，微服务是领域模型的系统落地，DDD 是一种设计思想，它可以同时指导中台领域建模型和微服务设计，即 DDD、中台和微服务的铁三角关系。
中台本质上就是通过 DDD 方法从业务领域细分出来的某个子域
二、DDD适用场景
上DDD理论可以指导所有业务系统的分析设计与开发。但实际上DDD并不适用于所有的系统开发：
DDD的学习成本巨大，入手门槛高； 在DDD过程中引入领域专家梳理通用语言很难，现实中能做到的人很少并且需要耗费大量的时间和精力； 需要开发人员从产品出发，从技术思维转为产品思维，从数据模型设计转为业务模型设计； 系统构建、架构设计、编码与传统实现差异很大，对于开发人员是一个挑战。
但是单从系统的角度来衡量，如果系统符下几下几点之一：
业务复杂：系统越来越大，业务越来越复杂，所有的业务都杂糅在一起，系统庞大不容易维护。 需求迭代快：对于核心需求和非核心需求的需求频率都非常大；非核心需求占用了大量资源。 系统中涉及到的垂直业务多：不同的业务可以化为不同的领域；
三、为什么要用DDD
统一业务语言：通过使用统一的领域语言，消除了团队间的分歧，提升团队间的沟通效率。
沉淀业务知识：通过领域模型沉淀领域知识，提升业务建模能力，清晰表达业务核心语义。
清晰业务边界：通过领域模型界定需求实现范围，统一各个子域的边界。
提升变化应对：通过领域模型与数据模型分离，将核心与非核心业务隔离，提升架构应变能力。
DDD可以解决软件复杂度
对于业务量大的系统，可以借助限界上下文进行分而治之 对于结构复杂的系统，可以通过DDD的分层架构进行层之间关注点分离。 对于业务复杂的系统，可以以领域为核心，识别变化，通过高内聚低耦合的设计，来提高程序的扩展性。 DDD是如何解决复杂度的问题
DDD通过战略和战术两个方向来解决复杂度的问题。
战略方向：强调以领域为核心，通过限界上下文和分层架构将关注点分离。借助六边形模型、用户故事等方式提炼领域知识，进而形成统一语言。建立领域模型，指导程序设计。 战术方向：引入了实体、值对象、聚合、领域服务、领域事件、工厂、仓储、应用服务等概念，指导我们进行程序设计。
四、DDD怎么实现
DDD的实现过程主要分为以下几个步骤：
分析业务需求
提炼统一语言
建立领域模型
完成程序设计
编码实现
在实现以上步骤时由分为两个阶段：
战略设计阶段
此阶段属于业务架构，通过 DDD 的理论，从业务的角度梳理出相应的限界上下文，通过统一的领域语言从战略层面进行领域划分以及构建领域模型。
战略设计主要包括：
领域/子域 通用语言 限界上下文 架构风格 战术设计阶段
此阶段属于技术架构，战术设计则将战略设计进行具体化和细节化，以领域模型为战术设计的输入，以限界上下文作为微服务划分的边界进行微服务拆分，在每个微服务中进行领域分层，实现领域模型对于代码的映射，从而实现 DDD 的落地实施。
战术设计主要包括：
领域模型（值对象、实体、领域服务、领域事件） 资源库（从存放资源的位置获取、添加、删除或者修改领域对象） 工厂(负责领域对象的创建，用于封装复杂或者可能变化的创建逻辑） 聚合(封装一到多个实体与值对象，表示边界，并维持边界范围之内的业务完整性） 应用服务 实体 值对象
