系统设计思想之Domain驱动

一、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的通用子域和支撑子域，实现企业可复用的通用业务能力，核心中台对应DDD的核心子域，这部分是DDD战略设计落地的产物。

        领域模型和限界上下文，则与中台建设中的微服务对应，DDD建立的领域模型可以作为微服务划分的依据，完成微服务的拆分和开发，这部分是DDD战术设计落地的产物。

        中台业务抽象就是领域建模的过程，系统抽象就是微服务设计过程，中台业务建模和落地，大致分如下几步

        1、选取主领域模型，按照业务流程节点，将业务划分为业务中台（多个核心子域），将通用的功能和支撑划分为通用中台（通用域，支撑域），较大范围的业务领域，需要再逐级划分为大小合适的领域再构建领域模型

        2、选取逻辑相对完整的领域模型作为主领域模型（如用户这个领域对象，常常分散到不同的领域模型中）以主领域为基准，扫描其他中台领域模型，检查是否存在功能重叠的模型，合并到主领域模型，完成领域模型的提炼

        3、选择其他主领域模型重复第二步，直到完成所有领域模型的比对

        4、将领域模型作为微服务设计的输入，完成微服务拆分和设计

 

 　　

　　参考书籍 ——《基于DDD和微服务的中台架构与实现》欧创新、邓頔
　　参考书籍 ——《领域驱动设计》Eric Evans
　　参考书籍 ——《架构真经》Martin L. Abbott