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