架构设计技能树详细版 v1
2021-09-24 12:35:58 124 举报AI智能生成
DDD 理论脑图
作者其他创作
大纲/内容
DDD领域驱动设计
通用语言<br>Ubiquitous Language
概念
通过团队交流、达成共识的、能够准确传递业务规则的、简单：语言
特点
通用，简洁、“无歧义”
价值
解决了交流障碍问题，使领域专家和开发人员协同合作
同名的业务词汇与实际业务关系不清
同名的业务词汇与不同的业务词汇关联
同名的业务词汇之间的关系不清楚
领域模型<br>Domain Model
概念
把通用语言表达成软件模型
特点
综合了系统分析和设计
语言、模型、代码三者紧密绑定
可以通过UML类图来展示
领域<br>Domain
本质
领域与具体开发技术无关，就是你的软件系统要解决的实际问题相关的所有东西的集合
解决方案空间：如何实现软件以解决这些业务挑战
问题空间：业务所面临的问题和挑战
子域<br>Sub Domain
包含
核心域<br>Core Domain
业务系统核心价值所在
支撑子域
通用子域
例子
电商网站
核心域：销售子域
通用子域：日志子域
支撑子域：除了销售子域之外的子域，如物流子域
限界上下文<br>Bounded Context<br>
概念
限界
一个界限，某个具体的范围
领域模型的边界
上下文
语境
本质
保证模型概念的清晰和无歧义，避免具有多重含义和职责的模型
例子
商品
在采购上下文中 - 补货商品
在售后上下文中 - 售后商品
如何划分
语言二义性
变化一致性
业务相关性
概念相关性
与技术组件保持一致（保持一致的模型认识）
一个团队
一个IDEA工程
一个部署单元
梳理关系
上下文映射图<br>Context Map
描述不同Context下模型的联系点
上下文依赖
应用服务<br>Application Service
表述应用行为
eg.购物车结算=>应用行为
隐藏领域层的复杂性及其内部实现
领域服务<br>Domain Service
表述领域行为
eg.金额计算、支付、生成订单=>领域行为
聚合<br>Aggregate
来源
UML类图概念，整体与部分的关系
eg.车和轮胎=>可以独立存在
DDD中的概念
领域对象的<b>显示分组</b>
封装业务
保证聚合内领域对象的数据一致性
关键
领域对象间的关联关系
基于<b><font color="#f15a23">业务用例</font></b>而非现实生活建立必要关联
减少不必要的关联
将双向关联转换为单项关联
领域不变性
领域内需要关注的业务规则
难点
一致性的维护
聚合内实现事务一致性
聚合外实现最终一致性
设计
一个持续性的活动
无法一口吃个胖子
持续改进聚合的设计
实体<br>Entity
概念
实体=唯一身份标识 + 可变性【状态（属性） + 行为（方法或领域事件或领域服务）】
特征
唯一标识
委派标识
为了迎合ORM而创建，和领域实体标识无关系
领域标识
基于领域实体概念分析确定的唯一身份标识
eg.支付宝交易流水号
生成时机
即时生成
延迟生成
可变性
实体的状态
eg.订单状态：未支付、正常、已发货、关闭
实体的行为
eg.订单行为：支付、发货、关闭
值对象<br>Value-Object
概念
<b><font color="#f15a23">值对象=值+对象</font></b> => 将一个值用对象的方式进行表述，表达一个具体的固定不变的概念
值的特征
表示一个具体的概念
通过值的属性对其识别
属性判等
固定不变
案例
购物网站的客户收货地址信息
作用
符合通用语言，更简单明了的表达简单业务概念
简化设计，减少不必要的数据库表设计
值对象不会孤立存在，可作为所属实体的数据列
多个值对象序可以列化到单个列
建模
结合通用语言的表述检查其是否具有值得的含义和特征
仓库<br>Repository
特性
一个聚合的集合
存储集合
删除集合
要点
通过<b>聚合根</b>来持久化和检索领域对象
隐藏聚合持久化和检索的底层技术实现
定义数据模型与领域模型的<b>边界</b>
映射
ORM
仓储使用ORM持久化领域对象的状态
定义
领域模型与持久化存储之间的明确契约
实现
泛型仓储
简化代码
明确意图
事务管理
UnitOfWork (UOW)
领域事件<br>Domain Event
基本概念
捕获领域中发生的具有业务价值的一些事情
eg."订单支付成功"=>一个领域事件
建模领域事件
核心
封装不变，应对万变
要点
事件源
事件处理
实现
发布-订阅模式
事件总线 (EventBus)
最终一致性
案例
订单系统发布"订单成功支付"事件
库存系统订阅并处理库存扣减逻辑
通知系统订阅并处理拣货通知
实现
事件存储
事件发布可用于重新发布
通过消息中间件去分发事件
事件溯源
事件源
用于恢复到某个状态
工厂<br>Factory
目标
隐藏对象的复杂创建逻辑
表达对象实例化的意图
实现
简单工厂
工厂方法
抽象工厂
反射工厂
好处
将领域对象的使用和创建分离
隐藏创建复杂领域对象的业务逻辑
根据调用者的需要创建相应的领域对象
封装聚合的内部状态
模块<br>Module
抽象
对领域模型进行分解的产物，相对独立的功能单元
由一系列高内聚的领域对象组成
设计
根据领域来组织模块
基于通用语言
模块命名规范
高内聚低耦合
模块内高内聚
模块间低耦合
实现
通过命名空间进行分离
使用单独项目进行分离
架构风格<br>Achitecture
分层架构<br>Layered Architecture
UI层
为外部用户访问底层系统提供交互界面和数据表示 e.g 接受和校验用户输入、输出JSON/XML的数据
Facade层
分离UI和应用层，将应用层数据mapping成UI层适用的数据
应用层
定义系统业务功能，编排领域层中的领域对象实现功能
领域层
概念
描述正在解决的问题及对应的解决方案
包含
领域模型映射的代码
基础设施层
为领域层提供技术支撑 e.g 持久化、序列化、消息通知
六边形架构（端口和适配器）<br>Hexagonal Architecture<br>
端口
Application和Domain层通过端口（一般是API）与外部通信
适配器
针对不同的外部资源，可以对接不同的适配器
保证内部逻辑的独立，和外部依赖解耦
面向服务<br>SOA<br>
松耦合：由于服务自治，有一定封装边界，服务调用交互是通过发布接口。这意味着应用程序不感兴趣的服务如何被实现<br>
位置透明：服务的消费者不必关系服务位于什么地方。<br><br>
可在异构平台间复用。可以将遗留系统包装成服务。<br>
便于测试，能并行开发，较高可靠性和良好可伸缩性
RESTful
松耦合（同SOA）
HTTP的成熟设计
HATEOAS
命令查询职责分离<br>CQRS
Command - 改变对象状态
Query - 返回对象数据
解决领域模型显示的复杂性
事件驱动<br>Event Driven
管道和过滤器
长时处理过程Saga
TODO
事件源
TODO
网格
TODO
疑问
领域、子域、限界上下文
为什么要有子域
子域的划分
架构设计的终极大招还是By Experience ——靠经验吃饭
收藏
0 条评论
下一页
