架构师篇-10、DDD实战篇：通过领域模型落地系统

进步一下

已于 2024-07-14 11:30:14 修改

阅读量485

点赞数 4

文章标签：经验分享

于 2024-06-30 22:54:35 首次发布

本文链接：https://blog.csdn.net/shanshe7934/article/details/140087781

版权

基于领域模型的设计与开发

数据库设计
程序设计
微服务设计

在线订餐系统的领域事件通知

在这里插入图片描述

微服务拆分

在这里插入图片描述

事件风暴会议

梳理领域事件
进行领域建模
识别聚合关系
划分限界上下文

用户下单领域模型

在这里插入图片描述

更新后的模型

在这里插入图片描述
订单表针对用户信息增加了冗余信息。

领域模型的设计实现过程

在这里插入图片描述

数据库设计

数据库映射：一对一关系

在这里插入图片描述

数据库映射：多对一关系

在这里插入图片描述

数据库映射：一对多关系

在这里插入图片描述

数据库映射：多对多关系

在这里插入图片描述

NoSQL数据库的设计

在这里插入图片描述

数据库映射：继承关系(1)

在这里插入图片描述

数据库映射：继承关系(2)

在这里插入图片描述

优点：

设计简单易懂
数据增删改容易
缺点：
查询统计性能低
设计带Union语句的视图

数据库映射：继承关系(3)

在这里插入图片描述

NoSQL数据库设计

在这里插入图片描述

服务/实体/值对象

服务（Service）
- 领域建模中标识某些行为或操作
实体（Entity）
- 领域建模中表示每一个业务个体的领域对象
值对象（Value Object）
- 领域建模中表示某个客观事物的领域对象

贫血模型的设计

在这里插入图片描述

充血模型的设计

在这里插入图片描述

聚合（Aggregate）

在这里插入图片描述
聚合关系的定义：订单删除了订单明细也会删除，不会单独只存在订单明细，订单创建完之后同时创建订单明细。
支持ddd的底层：demo-service2-support

工厂（Factory）/仓库（Respository）

在这里插入图片描述

领域驱动设计 vs 非领域驱动设计

在这里插入图片描述

领域驱动设计的分层架构

仓库：DAO
在这里插入图片描述

微服务的分层

在这里插入图片描述
错误的微服务设计

小而专的微服务设计

限界上下文

在这里插入图片描述
限界上下文的设计原则

限界上下文之间：低耦合
- 耦合：元素（模块、类、方法）之间相互依赖
- 当某元素需要变更、拓展、复用时，因为耦合使得这种变更、拓展、复用变得困难
- 最极端的低耦合：谁都不去依赖
限界上下文内：高内聚
- 内聚：某个元素只做自己职责之内的事情，将职责之外的事情交给别人去做，自己只是调用
- 高内聚的内涵与作用：单一职责原则

微服务的实现

在这里插入图片描述

去中心化数据管理

在这里插入图片描述

微服务架构实现读写分离

在这里插入图片描述

数据库纵向切分

在这里插入图片描述

跨库关联查询解决方案

在这里插入图片描述

订单状态的跟踪查询

在这里插入图片描述

案例：远程智慧医疗系统系统重构

在这里插入图片描述

初期：传统的诊所管理系统

在这里插入图片描述
如何向领域驱动转型？
分析原有诊所系统的业务流程，进行事件风暴，梳理领域事件。

在这里插入图片描述

领域事件分析

自己想的领域事件：挂号事件、接诊开单事件、结算事件、体检事件、取药事件。
实际的：已预约、已挂号、已接诊、已体检、已确诊、已开药、已缴费、已取药
在这里插入图片描述
在实际操作中，已确诊和已开药一般是同时发生的，因此已确诊和已开药可以做合并。

查找医生是否要作为领域事件？答：不需要，查找医生只是一个过程，不是领域事件。

再次分析，整体的领域事件还缺2个部分、已排班、已注册。
在这里插入图片描述

针对每个领域事件分析跟这个领域事件相关的人和事

在这里插入图片描述

疑问：这样的分析会带来什么样的帮助？
比如预约事件就是一个领域对象，最终会存储一个预约单(表)。

处方和药品明细有一个聚合的关系，因此有一个紫色标签表示有聚合关系。

在这里插入图片描述

领域建模——患者预约

按照一个个的领域事件建立领域模型。
在这里插入图片描述

领域建模——医生接诊

在这里插入图片描述

限界上下文

梳理完模型后发现患者和医生在这几个领域事件中是共享的，因此划分限界上下文时会将患者和医生单独划分为限界上下文。下图的上下文都为主题域（核心功能）：
在这里插入图片描述

互联网转型：远程接诊平台

从一个平台只管理自己的诊所，到连锁式的诊所管理平台。医生可以通过平台接诊多个诊所的患者。
在这里插入图片描述

从战略上分析系统

系统规划与架构设计
在这里插入图片描述

用例模型分析业务流程

由粗到细，第0层开始。

第0层用例模型

在这里插入图片描述

第1层用例模型：诊断治疗系统

在这里插入图片描述

第1层用例模型：诊所管理系统

在这里插入图片描述

用例描述文档输出

为每个用例输出用例文档（如prd），复杂用例分出子用例。查询报表用例模块（分析系统）关注点是内容
在这里插入图片描述
子用例

查询报表

图表展示

在需求讨论中建模
在这里插入图片描述
领域分析与领域模型

细化架构与对象分析（1）

细化架构与对象分析（2）
所有过错行为都不是过错，则执法行为正确。

细化架构与对象分析（3）

细化架构与对象分析（4）

原文分析法

分析结果
在这里插入图片描述
原文分析法

领域建模-患者预约

领域建模-医生接诊

微服务拆分

进步一下

关注

4
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
架构师篇-10、DDD实战篇：通过领域模型落地系统

聚合关系的定义：订单删除了订单明细也会删除，不会单独只存在订单明细，订单创建完之后同时创建订单明细。答：不需要，查找医生只是一个过程，不是领域事件。在实际操作中，已确诊和已开药一般是同时发生的，因此已确诊和已开药可以做合并。自己想的领域事件：挂号事件、接诊开单事件、结算事件、体检事件、取药事件。实际的：已预约、已挂号、已接诊、已体检、已确诊、已开药、已缴费、已取药。分析原有诊所系统的业务流程，进行事件风暴，梳理领域事件。再次分析，整体的领域事件还缺2个部分、已排班、已注册。细化架构与对象分析（2）
复制链接

扫一扫