中培企业IT培训
领域驱动软件设计实战训练营

什么是领域驱动设计

领域驱动设计(DDD)是由Eric Evans提出的一种软件开发方法,其核心思想是将业务领域的核心概念、规则和流程作为软件设计的核心驱动力。通过深入了解业务领域,开发人员能够设计出更符合业务需求的软件系统,提高系统的可用性和可维护性。

DDD强调与业务专家紧密合作,共同建立领域模型,使软件设计能够准确反映业务领域的实际情况。领域模型是DDD的核心,它是对业务领域的抽象和表示,有助于开发人员深入理解业务领域,从而设计出更优质的软件系统。

领域模型
什么是领域驱动设计

DDD和MVC的区别

大厂纷纷拥抱DDD,DDD究竟高在哪里

点击了解DDD相关岗位薪资水平

想进阶百万架构师,DDD 是必修内容

带你跨越DDD学习门槛,扫清DDD落地障碍

点击获取课程资料

五大模块+真实场景演练,手把手教你落DDD

领域驱动软件设计适合人群

点击立即咨询课程

领域驱动软件设计实战训练营课程大纲

第一天 第二天 第三天

第一单元 剖析领域驱动的设计思想

为什么我们需要领域驱动设计 1.现如今DDD越来越流行
2.DDD并不能帮助新项目的软件开发
3.DDD真正的作用是日后长期的维护
实践DDD的4大难题: 1.准确理解为什么要采用DDD?
2.怎样正确地进行业务领域建模?
3.怎样用领域模型指导开发与变更?
4.如何设计支持领域驱动的架构设计?
DDD真正的作用是应对日后的软件维护 1.我们现在面对的是快速变化的时代
2.变更越频繁,代码质量下降越快
案例:演示电商网站付款功能代码质量下降的过程
案例分析:揭示软件退化的根源
DDD的解决之道:业务领域建模
3.系统规模越来越大,系统越来越复杂
案例:演示嵌入式温控系统越来越难于维护的根源
案例分析:领域分析才是解决之道
DDD的解决之道:基于限界上下文拆分系统
案例分析:演示电商网站付款功能代码质量下降的过程 1.起初的设计
2.随后的变更
3.质量不断下降的过程
软件质量下降的根源: 1.软件总是因变更而变得越来越复杂
2.软件结构已经不再适应复杂的软件需求
3.必须要调整软件结构以适应新的软件需求
DDD的建模过程: 1.每次需求变更时先对需求进行领域分析
2.基于领域分析先进行领域模型的变更
3.基于领域模型的变更去指导程序的变更
DDD是应对软件复杂性之道 1.剖析领域驱动的设计思想
2.服务、实体与值对象的概念
3.充血模型与贫血模型的设计思路
4.问题域、子域与限界上下文划分
基于领域模型的设计变更 1.演练基于DDD的设计与变更过程
2.演练领域模型如何指导数据库设计
3.演练领域模型如何指导程序设计
4.聚合、仓库与工厂:傻傻分不清
5.限界上下文:系统拆分的利器
案例:重新演练电商网站付款功能的变更过程
第一个版本的领域模型与设计
第一次变更的分析设计过程
第二场变更的设计实现
第三次变更的设计实现
第四次变更与架构演化

第二单元 演练领域驱动的设计过程

领域建模分析过程 演练案例:在线订餐系统的领域设计过程
1.从领域中吸取知识
2.统一语言建模
3.事件风暴会议
1)梳理业务流程,识别领域事件
2)为每个领域事件识别参与者、行为、相关事物
3)标记事物之间的关系、聚合、聚合根
4)根据业务划分限界上下文
5)遍历所有事件,确定上下文映射
4.业务领域建模
1)为每个领域事件构建业务领域模型
2)划分主题域、支撑域、通用域
3)落实各子域之间的联系、接口及事件通知机制
基于领域模型的微服务设计 1.小而专的微服务设计
2.限界上下文与微服务拆分
3.上下文地图与微服务接口
4.各微服务中实体、值对象与服务的设计
5.各微服务中聚合、工厂与仓库的设计
6.领域模型4种关系3种继承的数据库设计
7.聚合层的设计、工厂和仓库的实现
8.基于DDD的微服务架构分层
解决DDD的设计难题 1.跨库查询的设计难题与设计实现
2.领域事件的通知机制与设计实现
3.微服务接口的防腐层设计
4.状态查询跟踪的设计思路与代码实现
分组练习:按照事件风暴的步骤进行业务领域建模 1. 召开事件风暴会议
2. 进行业务领域建模
3. 基于领域模型设计开发系统

第三单元 领域驱动设计实践

实战演练:远程智慧医疗大数据平台设计过程 1.系统业务规划与战略设计
2.子系统→限界上下文→功能模块划分
3.由粗到细的用例建模
4.各子域业务领域建模
1)智慧诊疗数据模型的领域分析
2)诊所管理信息系统的领域分析
5.各子域的接口设计
1)上下文地图的模型分析
2)微服务接口的方案设计
6.微服务的技术落地实践
1)去中心化的技术治理
2)微服务的技术中台
3)微服务的云端应用平台
起初:一个传统的诊所管理系统向互联网转型 1)起初没有采用领域驱动设计,也运行了这么多年
2)现在向互联网转型,业务变得越来越复杂,怎么开始领域建模?
第一步:站在全局的系统建设规划
第二步:DDD战略设计与限界上下文划分
第三步:各子域的业务领域建模
第四步:上下文地图与各子域的接口设计
转型成互联网连锁诊所系统,又该如何分析设计 1)基于领域模型进行新需求的分析
2)基于领域模型进行原有代码的更新维护
3)基于限界上下文进行微服务的拆分,以及这个过程中的坑
第一步:基于DDD进行战略设计的调整
第二步:各子域的业务领域建模调整
第四步:上下文地图与各子域的接口设计
第五步:基于DDD的微服务拆分
Ø基于DDD的数据库设计与去中心化的数据治理
Ø如何由原有的贫血模型向现在的充血模型改造
Ø如何解决跨库的关联查询与事务处理
Ø如何实现领域事件的消息推送机制
Ø如何实现跨库的状态数据查询
Ø如何打造基于整洁架构的领域驱动设计框架
增加人工智能的智能诊疗数据模型 1)如何通过领域模型来开展数据智能业务
2)如何基于领域模型的规划与智能系统的接口
3)基于领域模型的微服务+大数据的设计实践
分组练习:按照领域模型进行设计开发 1. 基于领域模型进行微服务的拆分与设计
2. 基于领域模型进行每个微服务的数据库设计
3. 基于上下文地图形成微服务间的契约与接口

第四单元 基于领域驱动的技术中台建设

DDD需要强大技术架构支持 1.降低技术门槛,减少开发工作量 → 制订规范、合理分层、降低复杂度
2.易于业务变更,易于架构演化 → 将业务与技术解耦
3.支持领域驱动,支持微服务 → 通用仓库、工厂及基础设施的设计
4.平台不断完善,功能不断积累 → 敏捷架构设计:架构跑道与使能故事
支持DDD的技术架构建设思路 1.分析当前软件架构设计与架构演化的痛点与根源
2.阐述技术中台的建设思路
1)将业务与技术解耦 → 整洁架构与六边形架构
2)提取共性,精简业务代码 → 单Controller,单Dao
支持领域驱动+微服务的技术中台 案例:在线订餐系统的应用
1.通用、可配置的DDD仓库与工厂的设计
2.解决跨库的关联查询与事务处理
3.纯洁的Service与Entity便于不断地架构演化
现有系统的整洁架构转型 1.系统级的重构方法与步骤
2.建立接口层解耦业务代码与技术框架的过程
3.基于整洁架构的技术架构演化与快速交付

第五单元 基于DDD的微服务设计实践

实战演练:高并发高可用的订单系统
微服务架构的6种设计模式 1.聚合模式 案例:电商网站购物功能的设计
Ø微服务前后端分离的设计
Ø分布式事务的两阶段提交
ØTCC方案与阿里Seata
演练:运用Seata实现微服务的分布式事务
Ø基于消息的最终一致性设计
演练:基于消息实现微服务的分布式事务
案例:电商网站下单服务的设计
单一职责原则与领域驱动设计
Ø互联网纵向切分在微服务的实现
Ø纵向切分应当注意的设计问题
Ø解决跨库关联查询的设计
演练:微服务间解决跨库关联查询的设计
2.代理模式 案例:电商网站多渠道支付的微服务实现
3.链式模式
4.分支模式
5.数据共享模式
案例:大数据与微服务结合的架构设计
案例:电商网站海量订单数据的秒级查询
6.异步消息模式
案例:电商网站异步化操作的微服务实现
微服务的拆分原则 1.能不拆尽量不拆:减少微服务间的调用
2.该拆分就得拆分
1)公共模块该拆分就得拆分
2)越来越复杂的模块该拆分就得拆分