DDD领域建模（适合比较复杂的项目）
2021-10-05 22:49:38 0 举报AI智能生成
关于面向领域建模的个人总结
作者其他创作
大纲/内容
什么是DDD
Domain Driven Design ，最初由 evic 在2004 年提出，主要解决具有共性的领域问题的一种软件思想。它并不是一种软件框架。
比如要做论坛->确定核心业务：用户发帖回帖
比如电商平台->都有商品浏览、购物车、下单、减库存、付款交易等核心环节
同一个领域的系统都有相同的核心业务。
DDD的核心概念
战略设计：主要关注核心子系统的设计，即如何拆分复杂的子系统。
引导拆分复杂的系统
电商举例
订单子系统
库存子系统
物流子系统
搜索子系统
用户中心。。。
经典拆分服务的规则
SRP 单一职责
ISP 接口隔离原则
AKF 可扩展的原则 通过加机器可以解决容量和可用性问题（如果一台不行就两台）
分支主题
康威定律/康威逆定律
沟通决定了设计、再多的事件也不能把事情做完美，但能把事情做完、种瓜得瓜种豆得豆（想做什么样的系统就搭建什么样的团队）、大型复杂的系统比小的系统更适合分解
DDD视角拆分
界限上下文二义性隔离
弹性边界隔离
问题子域边界隔离
聚合原子性
域，子域、界限上下文，UL
域：问题空间 如解决网上购物的问题
子域：把域拆分成更小更容易解决的问题空间
核心子域：如电商中的 订单、商品
支撑子域：如电商中的 支付宝、微信等结算方式
通用子域：如鉴权等通用的模块
界限上下文：解决方案空间，一个子域可能包含于一个或者多个 BC中。
举个例子：细胞之所以能存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，而且确认了什么物质可以通过细胞膜，BC可以理解为细胞膜
UL 统一语言，是团队共享的语言
战术设计：关注拆分好的子系统如何落地
划分 实体、值对象、聚合、工厂、资源库、领域服务、领域事件
聚合（Aggregate）
更类似于UML中的组合关系
帮助理解：比如去修轮胎，必须通过车来访问轮胎
聚合根：聚合之间通过聚合根关联引用，如果需要访问其他聚合的实体，先访问聚合根，再导航到聚合内部的实体；即外部对象不能直接访问聚合内的实体，具备唯一标识有独立的声明周期，一个聚合只能有一个聚合根
解决的问题: 复杂数据模型缺少统一的业务规则控制而导致的聚合，实体之间数据不一致的问题
职责：
1，作为实体，具备自己的业务属性，业务行为，业务逻辑
2，作为聚合的管理者
在聚合内部，负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑；
在聚合之间：它是聚合对外的接口人，以聚合根ID的方式接受外部请求和任务，实现上下文中的聚合之间的业务协同；
聚合过程实例
设计原则：
聚合设计的尽量小 如果聚合设计的过大，内部还有大量的实体和值对象，管理会比较复杂，高频操作会有并发和数据库锁冲突的问题，导致系统可用性降低； 聚合设计的足够小，也就降低了复杂度，可复用性也更高，降低了后期重构复杂聚合的成本；
聚合应该高内聚 封装的是真正的不变的领域对象，内部的实体和值对象按照固定的规则运行，实现数据的一致性，边界外的任何东西都于该聚合无关，
通过唯一标识符引用其它聚合 聚合之间通过聚合根的唯一ID来关联，而不是直接对象引用的方式，外部的聚合对象如果在本聚合范围内管理，容易导致边界不清晰，增加聚合之间的耦合度；
边界之外使用最终一致性 聚合内部数据强一致性，聚合之间数据最终一致性，在一次事务中最多只修改一个聚合的数据状态，如果在一次事务中涉及修改多个聚合的状态，应该使用领域事件的方式来异步的实现最终一致性，实现聚合之间的解耦；
在应用层实现跨聚合的调用 实现微服务内部聚合之间的解耦，以为为未来以聚合为单位的拆分和组合，应该避免跨聚合的的领域服务调用和数据表关联；
实体（Entity） DDD中的一类对象，拥有唯一标识符，经历各种状态变更后仍然可以保持一致，对这类对象而言，重要的是延续性和标识，
包含属性和方法（充血模型）、其中方法实现是实体自身的业务逻辑
具体的一类对象
值对象（Value Objects）通过对象的属性值来识别的对象是值对象，它将多个相关属性组合为一个概念整体。它是没有标识符的对象；
不关心唯一性、具有逻辑校验、等值判断等逻辑、只关心值的类
比如给办公室所有人点外卖 值对象：地址 不用关心每个人点的是什么，他们统一的值就是收货地址
资源库（Repository） 连接 datamodel 和domain model
根据具体的条件生成的用户想要的对象。资源库就是提供这些对象，并能供根据不同组合的条件筛选出数据提供显示。
领域服务（Domain Services）
领域服务是用来协调领域对象完成某个操作，用来处理业务逻辑的，它本身是一个行为，所以是无状态的。状态由领域对象（具有状态和行为）保存。
领域事件（Domain Event）
驱动领域中数据一致性
模块 （Modules）
DDD落地
传统四层架构
UI层、应用层、领域层、基础设施
App层：主要负责获取输入，组装context，做输入校验，发送消息给领域层做业务处理，监听确认消息，如果需要的话使用MetaQ进行消息通知
Domain层：主要是通过领域服务（Domain Service），领域对象（Domain Object）的交互，对上层提供业务逻辑的处理，然后调用下层Repository做持久化处理；
Infrastructure层：主要包含Repository，Config，Common和message，Repository负责数据的CRUD操作，这里我们借用了盒马的数据通道（Tunnel）的概念，通过Tunnel的抽象概念来屏蔽具体的数据来源，来源可以是MySQL，NoSql，Search，甚至是HSF等；Config负责应用的配置；Common是一写工具类；负责message通信的也应该放在这一层。
CQRS架构
单数据库 CQRS
分支主题
双数据库CQRS
分支主题
事件源CQRS
分支主题
战略设计、战术设计常用方法
四色建模法
业务关键时刻（红色）
角色（黄色）
人、事、物）（绿色）
描述（蓝色）
用例分析法
事件风暴法
领域故事讲述法
六边形架构
领域->应用->适配器->对应的具体服务层
分支主题
洋葱模型
分支主题
收藏
收藏
0 条评论
下一页
