讯享网

<dl aria-controls="tabs"> <dt> 第一天 第二天 第三天 </dt> <dd aria-current="true"> <p> <b>为什么我们需要领域驱动设计</b><br> 1.现如今DDD越来越流行<br> 2.DDD并不能帮助新项目的软件开发<br> 3.DDD真正的作用是日后长期的维护<br> <b>实践DDD的4大难题：</b><br> 1.准确理解为什么要采用DDD？<br> 2.怎样正确地进行业务领域建模？<br> 3.怎样用领域模型指导开发与变更？<br> 4.如何设计支持领域驱动的架构设计？<br> <b>DDD真正的作用是应对日后的软件维护</b><br> 1.我们现在面对的是快速变化的时代<br> 2.变更越频繁，代码质量下降越快<br> 案例：演示电商网站付款功能代码质量下降的过程<br> 案例分析：揭示软件退化的根源<br> DDD的解决之道：业务领域建模<br> 3.系统规模越来越大，系统越来越复杂<br> 案例：演示嵌入式温控系统越来越难于维护的根源<br> 案例分析：领域分析才是解决之道<br> DDD的解决之道：基于限界上下文拆分系统<br> <b>案例分析：演示电商网站付款功能代码质量下降的过程</b><br> 1.起初的设计<br> 2.随后的变更<br> 3.质量不断下降的过程<br> <b>软件质量下降的根源：</b><br> 1.软件总是因变更而变得越来越复杂<br> 2.软件结构已经不再适应复杂的软件需求<br> 3.必须要调整软件结构以适应新的软件需求<br> <b>DDD的建模过程：</b><br> 1.每次需求变更时先对需求进行领域分析<br> 2.基于领域分析先进行领域模型的变更<br> 3.基于领域模型的变更去指导程序的变更<br> <b>DDD是应对软件复杂性之道</b><br> 1.剖析领域驱动的设计思想<br> 2.服务、实体与值对象的概念<br> 3.充血模型与贫血模型的设计思路<br> 4.问题域、子域与限界上下文划分<br> <b>基于领域模型的设计变更</b><br> 1.演练基于DDD的设计与变更过程<br> 2.演练领域模型如何指导数据库设计<br> 3.演练领域模型如何指导程序设计<br> 4.聚合、仓库与工厂：傻傻分不清<br> 5.限界上下文：系统拆分的利器<br> 案例：重新演练电商网站付款功能的变更过程<br> 第一个版本的领域模型与设计<br> 第一次变更的分析设计过程<br> 第二场变更的设计实现<br> 第三次变更的设计实现<br> 第四次变更与架构演化 </p> <p> <b>领域建模分析过程</b><br> 演练案例：在线订餐系统的领域设计过程<br> 1.从领域中吸取知识<br> 2.统一语言建模<br> 3.事件风暴会议<br> 1）梳理业务流程，识别领域事件<br> 2）为每个领域事件识别参与者、行为、相关事物<br> 3）标记事物之间的关系、聚合、聚合根<br> 4）根据业务划分限界上下文<br> 5）遍历所有事件，确定上下文映射<br> 4.业务领域建模<br> 1）为每个领域事件构建业务领域模型<br> 2）划分主题域、支撑域、通用域<br> 3）落实各子域之间的联系、接口及事件通知机制<br> <b>基于领域模型的微服务设计</b><br> 1.小而专的微服务设计<br> 2.限界上下文与微服务拆分<br> 3.上下文地图与微服务接口<br> 4.各微服务中实体、值对象与服务的设计<br> 5.各微服务中聚合、工厂与仓库的设计<br> 6.领域模型4种关系3种继承的数据库设计<br> 7.聚合层的设计、工厂和仓库的实现<br> 8.基于DDD的微服务架构分层<br> <b>解决DDD的设计难题</b><br> 1.跨库查询的设计难题与设计实现<br> 2.领域事件的通知机制与设计实现<br> 3.微服务接口的防腐层设计<br> 4.状态查询跟踪的设计思路与代码实现<br> <b>分组练习：按照事件风暴的步骤进行业务领域建模</b><br> 1. 召开事件风暴会议<br> 2. 进行业务领域建模<br> 3. 基于领域模型设计开发系统 </p> </dd> <dd> <p> <b>实战演练：远程智慧医疗大数据平台设计过程</b><br> 1.系统业务规划与战略设计<br> 2.子系统→限界上下文→功能模块划分<br> 3.由粗到细的用例建模<br> 4.各子域业务领域建模<br> 1）智慧诊疗数据模型的领域分析<br> 2）诊所管理信息系统的领域分析<br> 5.各子域的接口设计<br> 1）上下文地图的模型分析<br> 2）微服务接口的方案设计<br> 6.微服务的技术落地实践<br> 1）去中心化的技术治理<br> 2）微服务的技术中台<br> 3）微服务的云端应用平台<br> <b>起初：一个传统的诊所管理系统向互联网转型</b><br> 1）起初没有采用领域驱动设计，也运行了这么多年<br> 2）现在向互联网转型，业务变得越来越复杂，怎么开始领域建模？<br> 第一步：站在全局的系统建设规划<br> 第二步：DDD战略设计与限界上下文划分<br> 第三步：各子域的业务领域建模<br> 第四步：上下文地图与各子域的接口设计<br> <b>转型成互联网连锁诊所系统，又该如何分析设计</b><br> 1）基于领域模型进行新需求的分析<br> 2）基于领域模型进行原有代码的更新维护<br> 3）基于限界上下文进行微服务的拆分，以及这个过程中的坑<br> 第一步：基于DDD进行战略设计的调整<br> 第二步：各子域的业务领域建模调整<br> 第四步：上下文地图与各子域的接口设计<br> 第五步：基于DDD的微服务拆分<br> Ø基于DDD的数据库设计与去中心化的数据治理<br> Ø如何由原有的贫血模型向现在的充血模型改造<br> Ø如何解决跨库的关联查询与事务处理<br> Ø如何实现领域事件的消息推送机制<br> Ø如何实现跨库的状态数据查询<br> Ø如何打造基于整洁架构的领域驱动设计框架<br> <b>增加人工智能的智能诊疗数据模型</b><br> 1）如何通过领域模型来开展数据智能业务<br> 2）如何基于领域模型的规划与智能系统的接口<br> 3）基于领域模型的微服务+大数据的设计实践<br> <b>分组练习：按照领域模型进行设计开发</b><br> 1. 基于领域模型进行微服务的拆分与设计<br> 2. 基于领域模型进行每个微服务的数据库设计<br> 3. 基于上下文地图形成微服务间的契约与接口 </p> <p> <b>DDD需要强大技术架构支持</b><br> 1.降低技术门槛，减少开发工作量 → 制订规范、合理分层、降低复杂度<br> 2.易于业务变更，易于架构演化 → 将业务与技术解耦<br> 3.支持领域驱动，支持微服务 → 通用仓库、工厂及基础设施的设计<br> 4.平台不断完善，功能不断积累 → 敏捷架构设计：架构跑道与使能故事<br> <b>支持DDD的技术架构建设思路</b><br> 1.分析当前软件架构设计与架构演化的痛点与根源<br> 2.阐述技术中台的建设思路<br> 1）将业务与技术解耦 → 整洁架构与六边形架构<br> 2）提取共性，精简业务代码 → 单Controller，单Dao<br> <b>支持领域驱动+微服务的技术中台</b><br> 案例：在线订餐系统的应用<br> 1.通用、可配置的DDD仓库与工厂的设计<br> 2.解决跨库的关联查询与事务处理<br> 3.纯洁的Service与Entity便于不断地架构演化<br> <b>现有系统的整洁架构转型</b><br> 1.系统级的重构方法与步骤<br> 2.建立接口层解耦业务代码与技术框架的过程<br> 3.基于整洁架构的技术架构演化与快速交付 </p> </dd> <dd> <p> 实战演练：高并发高可用的订单系统<br> <b>微服务架构的6种设计模式</b><br> 1.聚合模式 案例：电商网站购物功能的设计<br> Ø微服务前后端分离的设计<br> Ø分布式事务的两阶段提交<br> ØTCC方案与阿里Seata<br> 演练：运用Seata实现微服务的分布式事务<br> Ø基于消息的最终一致性设计<br> 演练：基于消息实现微服务的分布式事务<br> 案例：电商网站下单服务的设计<br> 单一职责原则与领域驱动设计<br> Ø互联网纵向切分在微服务的实现<br> Ø纵向切分应当注意的设计问题<br> Ø解决跨库关联查询的设计<br> 演练：微服务间解决跨库关联查询的设计<br> 2.代理模式 案例：电商网站多渠道支付的微服务实现<br> 3.链式模式<br> 4.分支模式<br> 5.数据共享模式<br> 案例：大数据与微服务结合的架构设计<br> 案例：电商网站海量订单数据的秒级查询<br> 6.异步消息模式<br> 案例：电商网站异步化操作的微服务实现<br> <b>微服务的拆分原则</b><br> 1.能不拆尽量不拆：减少微服务间的调用<br> 2.该拆分就得拆分<br> 1）公共模块该拆分就得拆分<br> 2）越来越复杂的模块该拆分就得拆分 </p> </dd> </dl>