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