一、DDD从放弃到入门
希望了解一套微服务框架的；希望学习到新技术的；开发的系统不复杂，模块少而独立的；当前自己设计的架构已满足拓展性，可复用性，技术与业务复杂度已分离的； 这几类人群不是DDD的目标人群，建议尽早放弃，学习领域驱动设计能得到的收获概括起来大致如下： 1、领域驱动设计是一套系统的设计思想，规范你的设计过程 2、领域驱动设计用于处理模块繁杂，业务复杂度高的产品研发，旨在将将业务复杂度与技术复杂度分 离，抽离出业务各个领域的核心内核，便于领域知识的复用 3、领域驱动设计强调技术专家和业务专家，通过统一的语言来完成领域的建模，帮助技术侧和业务侧形 成一套统一的语言 4、微服务与领域驱动设计天然搭配，微服务拆分中一直模糊的边界，可通过领域驱动设计来划分清楚 5、领域驱动设计能帮助提高大型系统的拓展和演进能力 二、什么是DDD 如下图，传统的敏捷开发模式，我们更多的使用数据驱动设计的思想，按照功能模块来，拆分成一个个的小模块，每个模块要实现什么功能，需要什么样的数据，然后就通过ER数据建模，建库建表后开干了，这样会导致N个系统中重复的功能会反复建设，Service层编写了繁杂的业务逻辑，耦合度极高，经常牵一发而动全身。
而DDD是指需求输入的时候，从领域开始聊起，比如教育是一个领域，先从校长聊起，然后聊到他的关联实体老师，学生，考试等等，这些实体之间的关联关系是什么，他们各自都会有哪些行为方法和业务逻辑。聊清楚后进行实体的建模，聚合实体的行为形成一个个领域服务，比如学生+老师的实体组合成了上课这一领域服务，之后再对领域服务进行编排，组成核心的可复用的业务逻辑。 再之后就是经过领域模型划分微服务界限，映射模型和微服务代码后进行开发，DDD就是以领域为入口，来解决产品设计，研发的思想。
DDD通过领域建模，编排核心业务逻辑后映射到微服务开发的过程，有利于构建出企业可复用的核心能力，减少重复的IT建设，同时开发者可以根据模型和微服务代码设计的对应关系，快速清晰的完成开发。同时后面博文会讲到DDD严格的分层结构设计，能够帮助构建一个“低耦合，高内聚”，可演进的系统。
三、DDD的战略和战术
DDD不是架构，而是架构设计思想，演进的方法论，旨在聚焦业务领域模型来控制业务的复杂性，同时分离技术和业务耦合的复杂性。
DDD包括战略设计和战术设计两部分战略设计：从业务视角出发，业务领域专家和技术专家通过事件风暴，建立共同的语言，构建领域模型，同时划分好领域的限界上下文，并以限界上下文作为微服务拆分和设计的边界，做业务核心逻辑的编排，从而在业务中台构建可复用的核心能力。
战术设计：从技术角度出发，聚焦于领域模型如何映射到微服务代码开发的实现上。限界上下文和领域模型作为输入，从领域模型中抽象出来聚合，聚合根，实体，值对象，领域服务，领域事件，应用服务编排，仓储等，以表格或其他形式一一对照模型去设计代码，并最终结合分布式缓存，消息最终一致性等基础支撑实现落地。 DDD按照一定规则将业务领域细分，细分到一定程度后，DDD将要解决的问题限定在特定范围内，这个过程中，可以将领域划分为子域，子域还可以继续划分为子子域，直到细分的程度，可以明确的区分不同业务领域，又不至于过度拆分，并适合微服务团队实施落地。DDD通常将划分后的子域区分为核心子域，支撑子域和通用子域。比如电商领域的子域划分
DDD这种子域的划分方法，可以帮助企业IT建设过程中确定中台的领域边界。
四、DDD，中台和微服务如何协同工作 业务中台的形成，实际也是业务领域不断细分，演进和能力沉淀的过程，所以中台是DDD战略设计的落地，DDD最擅长的就是领域建模。微服务的架构设计，参照着建模后的领域模型和限界上下文，作为微服务拆分的边界和依据，然后微服务与领域里的一个个子域互相映射，完成代码开发，是DDD的战术落地。
本文先从粗粒度来描述DDD战略设计和战术设计的实现，细粒度的实现待后面更新完子域，限界上下文，实体和值对象，聚合和聚合根，仓储模式，领域事件，分层架构等等后自然了解。下面看领域建模和中台建设，如何映射与关联。
参考书籍 ——《基于DDD和微服务的中台架构与实现》欧创新、邓頔
参考书籍 ——《领域驱动设计》Eric Evans
参考书籍 ——《架构真经》Martin L. Abbott