DDD—什么是领域驱动设计

一、DDD从放弃到入门 希望了解一套微服务框架的;希望学习到新技术的;开发的系统不复杂,模块少而独立的;当前自己设计的架构已满足拓展性,可复用性,技术与

一、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