DDD-思维导图
2022-07-28 19:29:17 78 举报
AI智能生成
领域驱动
作者其他创作
大纲/内容
发展一套领域模型的通用语言
提升测试收益
作用
说明:是语义和语境上的边界【逻辑】;边界内的每个代表软件模型的组件都有着特定的含义并处理特定的事务
问题空间是在给定项目的约束条件下进行高级战略分析与设计各个步骤的地方
问题空间ProblemSpace
真正实施解决方案的地方
这些解决方案在问题空间讨论中被识别为核心域(CoreDomain)当限界上下文被当作组织的关键战略举措进行开发时,即被称为核心域
解决方案空间SolutionSpace
限界上下文BoundedContext
用于表达边界内的软件模型
团队成员交流使用它,模型实现使用它
统一语言UbiquitousLanguage
处理边界问题
限界上下文被当做关键战略举措进行开发
MVP【Minimum Viable Product】
核心域
支撑域
通用域
分类
子域SubDomain
定义:多个限界上下文之间的集成关系
连接两个限界上下文之间的这条线段就代表上下文映射
定义了两个集成的限界上下文之间的团队关系及技术实现方案
上下文映射图Context map
合作关系
共享内核
客户-供应商
跟随者
防腐层
开发主机服务
已发布语音
各行其道
大泥球
映射的种类
基于SOAP的RPC
RESTful HTTP
消息机制
可靠的集成方式
上下文映射Context Mapping
宏观层面的战略设计
领域实体
聚合根
领域服务
明确的建立模型
把模型内部发生的事情分享给需要知道这一切的系统系统:本地限界上下文或者其他的远程限界上线文
事件溯源
领域事件Domain Events
战术设计
建模工具
什么是抽象
抽象的层次性
寻找共性
提升抽象层次
构筑金字塔
如何进行抽象
多阅读
多总结
领域建模训练
如何提升抽象思维
抽象
分治的标准:高内聚低耦合
归并排序
二分搜索
K选择的问题
分治算法
函数分解
写代码的二次创作
分治模式
分层网络模型
传统MVC三层架构
面向领域的四层架构
分层架构
分治设计
横切和竖切
分而治之
核心思想
oop
design pattern
SOLID
基础知识
软件开发被视为成本中心而非利润中心
热衷技术并通过技术解决问题,而不是深入思考和设计
过于重视数据库
发人员使用“任务板挪卡”而非考虑周详的设计导致他们造出了一个个“big ball of mud”,而不是业务驱动下恰当的分离模型
开发人员在用户界面和持久层组件中构建业务逻辑。此外,开发人员也经常会在业务逻辑当中执行持久化操作
项目中存在错误的抽象级别,表现为开发人员试图借助过度概括的方案满足所有当下以及臆想出来的未来需求,而不是解决实际而又具体的业务诉求。
在紧耦合服务群中,当一个服务执行操作时,该服务直接调用另一个服务并引发一个对等操作。这种耦合会经常破坏业务流程和未达成一致的数据,更别提这样的系统会有多难维护了。
潜在问题
什么是?
数据驱动和领域驱动
统一语言
面向对象【oop】
业务语义显性化
分离业务逻辑和技术细节
完美匹配微服务
DDD的优势
解决领域模型到设计模型的同步、演化;将反应了领域的设计模型转换为实际的代码
核心诉求
基础概念
用例分析法
四色建模发
便利贴
可用范围:宏观【big-design】的建模和设计级别【Design-level】的建模
橘色
事件的名称应该是动词的过去式
纵向的空间来表示并行处理的领域事件
领域事件
浅蓝色
摆放在由它引起的领域事件的左边
它们被成对地关联在一起:命令/事件、命令/事件、命令/事件,一对接一对
有些领域事件是由即将到达的时间期限引起的,因此不存在对应的显式命令导致它发
把命令和领域事件便利贴一起贴在聚合便利贴上
命令
长方形的黄色即时贴
这是第一级分类,可以被认为是一组事件操作的“事物”
是一个名词,可以在一组相互依赖的事件中识别出来
黄色+小人
在浅蓝色命令的左下角
只有当关于用户和系统交互的重要事项,或者系统针对用户的特定角色要完成的事情需要交流时,才展示
执行动作的特定用户角色
浅紫色
领域事件触发执行流程
从领域事件开始绘制一条带箭头的连线,最终指向这个命名流程
执行的流程(Process)
粉红色
摆在不同的区域边界内,并在这些便利贴上写上代表该区域内容的名字
限界上下文
表示领域事件在限界上下文之间的流动方向
箭头
绿色
识别用户执行操作所需的各种视图(View),以及不同用户的关键角色
只展示重要的
视图
颜色区分
事件风暴【event storming】
根据需求划分出初步的领域和限界上下文,以及上下文之间的关系
进一步分析每个上下文内部,识别实体和值对象
对实体、值对象进行关联和聚合,划分出聚合的范畴和聚合根
为聚合根设计仓储,并思考实体和值对象的创建方式
在工程中实践领域模型,并在实践中检验模型的合理性,倒退模型中不足的地方并重构
设计过程
影响力地图【Impact Mapping】
用户故事地图【User Story Mapping】
验收测试
SWOT分析法
领域建模
CQRS-命令和查询职责分离
六边形架构
洋葱架构
事件驱动架构IDDD
测试驱动架构TDD
响应式架构和Actor模型
具体状态传输REST
面向服务架构SOA
微服务架构
典型的应用架构
软件架构
分层设计
扩展设计
规范设计
COLA Archetype
COLA架构设计
单元测试
集成测试
COLA Mock
COLA测试
COLA架构总结
COLA架构
实践
失血模型
对象只是数据为载体,没有行为
以数据为中心,已数据库ER设计作为驱动【自下而上的方式进行设计】
采用Action/Service/Dao的分层结构;只是对数据进行移动、处理、实现的过程
业务逻辑复杂时,业务逻辑、状态会散落到大量的方法中,原本的代码意图逐渐不明确
贫血模型
贫血症和失忆症
将数据和行为封装在一起,并与现实世界中的业务对象相映射【oop】
各类具备明确的职责划分,将领域逻辑分散到领域对象中
充血模型
胀血模型
贫血模型=》充血模型
DDD
0 条评论
回复 删除
下一页