
开课计划
城市 | 天数 | 价格 | 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 7月 | 8月 | 9月 | 10月 | 11月 | 12月 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
北京 | 3 | 7800 | 24-26 |
课程大纲
课程安排:
第一天
第一单元 剖析领域驱动的设计思想
为什么我们需要领域驱动设计
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)越来越复杂的模块该拆分就得拆分
主办单位:
上海复锐企业管理咨询有限公司
联系方式:
电话:021-65210156、021-65214838 18917636997
网址:www.free863.com
周末及下班时间服务热线:13817832229
授课讲师
范老师
畅销书籍《架构真意》与《大话重构》的作者,规模化敏捷SPC。曾任航天信息首席架构师,哈工大软件工程硕士,软件架构及重构的客座讲师。从事软件研发工作近二十年,并且现在一直坚守在大型软件架构设计一线工作。从需求分析、软件开发到项目管理、架构设计都有丰富的从业经验。先后参与了数十个国内大型软件项目,涉及国家财政、军工、税务、医疗等领域的大数据中台建设、风险防控与人工智能研究。互联网转型、微服务转型及大数据转型的实践者与倡导者。同时,还是大型遗留系统改造专业户,多次参与大型遗留系统改造、软件系统重构等重大项目,长期关注大型业务系统的品质保证、防止腐化以及技术改造等困扰软件企业的问题,在遗留系统优化与改造方面有丰富的经验。
程老师
中国科学院软件研究所硕士,主要研究方向:架构设计、项目管理实践、大型高可用高并发架构设计、微服务架构、软件测试等等。熟悉网络分布式计算、数据库、网络操作系统,精通J2EE、SQL、中间件服务器。在J2EE技术领域具有理论功底和实践经验。在J2ME商务应用和基于J2ME游戏开发领域具有深厚的理论功底和丰富的实战经验。主要授课方向:DevOps落地实践、微服务架构、软件构架设计、UML、GO语言、OOAD、J2EE企业级高级应用开发等。 擅长架构企业级应用;有独立工作流引擎开发、企业系统应用集成方面的丰富经验;在企业门户(Portal)、报表、工作流引擎和企业服务总线(ESB)等应用领域有深入的理论研究和充分的实践;对软件开发的整个流程有深刻认识,有很好的协作精神和学习能力。在架构下的系统设计和开发方面均有丰富经验。能够结合实际,在复杂的应用环境中选择适合的技术组合并合理利用开源中间件来降低项目开发风险、缩短开发周期、提高应用系统的可维护性和可扩展性。