《领域驱动设计-软件核心复杂性应对之道》图解
2022-04-25 16:44:45 0 举报领域驱动设计-软件核心复杂性应对之道图解
作者其他创作
大纲/内容
概论
模型表达现实
领域驱动的本质是模型驱动
一 发挥领域模型作用
1.0 让DM 发挥作用
模型和设计相互影响、模型是团队语言中枢、模型是浓缩的知识
软件的核心是为用户解决领域相关的问题能力
1.1 消化知识
模型和现实绑定
获得基于模型的语言
开发蕴含知识的模型
提炼模型
头脑风暴和试验
深层模型
1.2 语言的交流和使用
领域专家 行话
Ubiquitous language 公共语言
模型作为语言中心
一个团队一种语言
设计细节要在代码体现
文档结合模型
解释性模型
1.3 绑定模型和现实
MDD 模型驱动设计
设计反应领域模型
建模范式-模型、范式、设计
建模人员参与开发-设计开发不能割离
二 模型驱动设计组件
2.0 模型设计构造块
服务-service
实体-entity
值对象-Vo
分层-layerred-隔离
仓储-repository-载入
聚合-aggregate-整合
工厂-factory-封装
2.1 分离领域
传统DDD 四层架构（表示、应用、模型（DDD）、基础设施）
单向依赖，上层通过接口操作下层
分离方式-分层、限界
2.2 软件中的模型
关联
Entity-Reference Object 关联对象
RO-生命周期连续性、状态不是由属性决定
RO-明确满足什么条件才是相同事物
VO-只使用期属性、不可变、无标识
Service-不属于RO和VO 的领域相关行为
Service -不要替代RO 和VO行为
Service 原则上要求无状态
Module -package
2.3 领域对象生命周期
聚合-AggreGate
聚合根-RO 隔离外界
Factory-创建对象&重建对象
Repository-隔离对象和关系型数据库
2.4 扩展实例
1 读写 争用比较明细的对象 拆分不同的聚合，减少相互影响。
2 module 之间保持低耦合高内聚，之间关系不能复杂。
三 模型重构
3.0 通过重构加深理解
深层次模型探索
微重构概念-解决一些从代码中可以观察到的问题
宏观重构-领域模型重构
对象分析的传统方式：提炼需求文档中的名词和动词
开发的代码可以反馈开发对模型的理解深度
为开发者编写代码，方便扩展和修改
3.1 突破
通过重构转型为DDD
找出和领域专家理解一致的模型
重构小步进行，保持系统正常运行
3.2 将隐式概念转化为显示
发现现有设计问题和不足
和领域专家沟通
阅览领域书籍
研究领域先辈的开发经验
DDD--->MDD
约束---隐式规则
领域对象（领域行为，领域约束）
领域对象分为两种 实体对象 值对象
宿主对象
MDD 模型表达现实
数据库查询干扰领域
DDD 和软件工程 是什么关系
DDD 是软件设计思想
JAVA Spring 是编程工具，思想指导工具的使用方式。
3.3 柔性设计
命名类和操作时 要描述他们的效果和目的，而不是实现方式
Value Object 除创建方法外只包含函数
函数：不改变系统状态的计算方法
命令（操作）：改变系统状态有副作用的方法 ，仅EntityObject 可以包含。
查询：只查数据没有副作用的方法
封装的意义-看框架源码时可以通过封装的接口名称 方法名称 明确其含义 而非一行一行看代码
Module 和 aggregate 的目的都是为了限制相互依赖的关系网。
概念过载：当一个对象 承担了过多的责任和逻辑就会出现概念过载
申明式编程风格 ，让代码读起来像是领域中业务场景的概念定义，而不是一处理逻辑。
闭合操作=申明式+无副作用
3.4 分析模式的应用
规则对象 Assert
Side-effect-free-function
3.5 将设计模式应用到 模型
设计模式 和 领域 模式
设计模式注重解决复杂问题的技术方案实现
借鉴设计模式-策略模式-的思路来整理领域中过程和规则的设计方式
模型 --模式 --模式思想
组合模式-部分和整体具体相同的特性和操作，可以实现递归操作
领域模式特征：适用于模型也要适用于现实
3.6 通过重构来得到更深层理解
柔性设计：例子 手指，关节处是柔性设计，关节受伤 修复容易，非关节要变化就严重了动骨头了。
重构 -明面上的修改 和 暗构-暗地重构植入基因
持续重构
四 战略设计
4.1 保持模型完整性
banded Context
context map
接触点 、 关系线
模型转换 数据转换-转换器 适配器模式
关系类型 ： 共享内核，订阅
共享子集 core domain ,generic subdomain
定义Bounded Context 的目的是把模型统一在特定边界之内
领域逻辑（业务逻辑）+技术逻辑 =分层架构
团队通用语言 ，类似于 “行话”
领域模型是业务资产
4.2 精练
明确Core Domain
领域模型是业务资产，业务价值
业务开发 关注业务价值，业务价值是企业的核心
领域前景说明 ，核心突出
通用子域 代码可以 复用 可以购买 可以开源，例如 客户域 、财务域。
项目风险=技术风险+领域风险
封装的意义 是把 做什么和如何做分开
Core Domain > Generic SumDomain
Core 精炼 方法 分割，减少关系，明确关系
软件价值点是企业特有的部分，非通用部分和支持部分
精炼的目的是把模型设计的更明显
4.3 大比例结构
复杂的模型 纵向切 不足以简化理解，还需要加上横向切 ，模块+分层
大比例结构划分的目的是保留开发一定的自由度 同时 时模型不会混乱
系统隐喻 、幼稚隐喻
大比例结构的价值随着复杂度的增加而增加
分层应该显示出业务优先级
潜能层-能够做什么
作业层-打算做什么 正在做什么
知识级别知识层（元数据+配置定制功能？模糊）
可插入式组件框架对应高层抽象
宽泛但严格的规则
4.4 综合运用
模式融合
上下文 精练 大比例结构 互为补充
上下文和分层结合
一个系统的模型 使用的结构不宜过多
分层 分包
架构师制定战略决策
不要脱产的架构师
战略设计开发团队要参与其中共同认知
总体规划
总结
这本书并不高大和精尖，但它就像一把利斧劈开了我的内心，把我的软件从业十年困惑暴露在烈日下，直视我的血脉。并且试图架构一种答案。
收藏
收藏
0 条评论
下一页
