架构师第十周

这周收获颇丰, 主要是了解到DDD的知识, 之前也学过极客时间的DDD实战, 但比较晦涩.



总结下来主要分五块内容: 为什么要DDD (即DDD的作用)、DDD战略设计、DDD战术设计、DDD架构、实战例子



为什么要DDD?

DDD可以维护正确的模块逻辑设计, 维护业务一致性, 产品一致性, 内部实现一致性.



DDD战略设计

领域、子域: 将大的领域划分为小的子域

界限上下文: 每个子域都有一个界限上下文, 用来控制子域的边界

上下文映射图: 描述不同子系统或模块之间的各种交互



战略设计可以看做是我们设计领域模型对象的指导方针, 在做领域模型设计时, 时时关注领域、子域的上下文, 确定上下文才能保证领域模型的一致性.

战略设计是划分模块和服务的边界及依赖关系



DDD战术设计

实体: 领域模型对象即是DDD的实体, 每个实体都有一个唯一标识, 实体的状态可能变化但唯一标识不变, 实体设计是DDD的核心. 而实体的责任, 即业务逻辑设计, 一定要结合业务场景和界限上下文

值对象: 不变性的对象, 尽量多将对象设计为值对象

聚合: 多个实体和值对象的组合, 他们可以聚合形成统一的单元, 并对外提供服务, 聚合也是有边界的



DDD分层架构

经典的分层架构, 即 [用户接口层]-[应用层]-[领域层]

领域层为实体, 应用层提供多领域层聚合调用



DDD实战

原有业务: 订单系统需要兼容各个业务线的规范, 提供支持接口供各个业完成"交付"工作



原改进方案: 订单系统上层加一个"订单代理系统", 相当于一个适配器模式的系统, 适配变化, 隔离订单系统和业务系统. 但还是被调用者, 需要兼容各业务规范



DDD改进方案:

问题梳理:

• 通过各领域的界限上下文分析, 发现每个业务都包含了"交付"的功能, 每个业务由于组不同, 规范不同, 而订单系统却要迎合所有规范



DDD分析:

• 既然每个业务组包含了"交付"的职责, 且各不相同改进困难, 应该剥离这块职责, 使用"订单交付系统"的领域来划分这块职责.



方案:

• 交付系统管理所有交付, 负责交付后的三方调用: 订单、支付、权益, 保证三方的一致性

• 交付系统充当框架类系统, 规范所有业务的交付相关接口, 当有交付需求时, 主动调用业务的接口, 获取所需信息并完成最终交付