DDD领域驱动模型设计

DDD

• https://www.jdon.com/
• DDD基于ROR
• 纯DDD落地实现框架：akka

好处

Domain driven Design

四色原型建模

分层架构

三层

• MVC

四层

好处

• DDD

  起点高，条件好，北京女朋友，海归，从恋爱走向结婚很平缓；

• 面向过程脚本

  起点低，条件差，只是为了解决单身找了个女朋友，长得一般，没上过学，家里穷，一但到后期谈婚论嫁你就不愿意了，就想分手了，无法维护了，难点就来了；

• 面向数据表

  起点一般，同学女朋友，家庭条件一般，持续的时间长一点，谈结婚也不想分手可维护，到后期麻烦越来越大，还没到特别大就给他拆分了；

缺点

领域模型 domain model

贫血模型

充血模型

优点

缺点

传统的数据驱动开发模式

比如scrum敏捷开发

• 一个功能一个功能最小原型设计，这些原型作为“统一语言”业务沟通；
• 产品拿着“统一语言”和研发沟通，需求分析会；
• 创建敏捷看板；
• 早上站会；
• 开始干活；

Bounded Context

什么是CQRS

Event Sourcing

统一语言（Ubiquitous Language）

saga分布式事务模式

聚合根

什么是DDD?

面向领域模型驱动整个架构

DDD弊端

• 没有成熟的框架，没有任何框架让你摸索和实现；

DDD不是架构，只是一种方法论，只是一种思想；

比如MVC

比如scrum敏捷开发

• 一个功能一个功能最小原型设计，这些原型作为“统一语言”业务沟通；
• 产品拿着“统一语言”和研发沟通，需求分析会；
• 创建敏捷看板；
• 早上站会；
• 开始干活；

DDD

• 不影响分析需求（不影响产品和业务的沟通）；

  

• 在domain（领域）上在做一层技术设计上的研究，研发和产品；

  

  

1. 在和客户聊需求时，只聊需求不聊domain；
2. 以domain和产品/客户聊需求；
   1. 聊属性：
      • 比如：汽车类（出场年龄、价格、几块玻璃、几个车轮、长、高）
   2. 聊关系：强关联关系 或者 包含关系，每个关系又有独立的领域，（方向盘、车轮、座椅、变速箱、车窗、发动机…有专门厂商去只造）
      • 方向盘
      • 车轮
      • 座椅
      • 变速箱
      • 车窗
      • 发动机
3. 既要有车轮又要有车的原型，这就是一个独立的领域；
   • 属性值
   • 其他模型（模型里套模型）

聚合根

根：root

聚合：原型/实体/值对象

把实体对象聚合到一起，有一个大佬称之为根对象，这个大佬就是聚合根；

领域模型

贫血模型：MVC三层架构

VO（value object）

• 指领域对象里只有get和set方法（POJO），所有业务逻辑都不包含在内，而是放在

充血模型

• 在领域对象中就已经初始化设计好了一些方法（属性、值对象、业务逻辑、dao）；

DDD专有名词

1. 领域2想修改领域2，就会访问领域1统一入口；

   

2. event source

   ：领域过多请求量过大，就会引入event source事件源驱动（数据源在事件驱动可以做到追溯版本），就像GIT记录修改版本记录，event source主要就是追溯数据源的；

   

3. CQRS

   ：Command Query Responsibility Segregation，数据量太大了，就引入CQRS读写分离；

   

4. bounded context

   ，这个领域设计的边界，从哪儿到哪儿，有几个方法几个属性；