领域驱动设计与实践——软件核心复杂性应对之道

【培训地点】：深圳

【培训费用】：3980元/人（培训费用、资料费、茶歇、结业证书、税费，一年内可免费复训）

注：此课程我们可以提供企业内部培训与咨询服务

解决的关键问题

领域驱动设计（Domain Driven Design，DDD）自诞生以来已有十几年时间，它是针对复杂系统设计的一套软件工程方法。由于面向对象分析与设计（OOA/OOD）的广泛应用，并且与前期需求分析和后期系统开发有机衔接，在行业产生广泛的影响，具有深远的指导意义。但是，由于软件的复杂度越来越庞杂和微服务的兴起，领域驱动设计通过分而治之控制软件规模，即一个大型复杂软件都是由一个或多个微服务组成的，系统中的每个微服务可被独立部署，微服务之间松耦合，且每个微服务只关注完成自己的任务并很好地完成任务。所以，领域驱动设计的思想和微服务架构风格的融合，从而指导复杂业务需求的软件系统的设计、开发与维护，降低了系统业务分析的复杂度和技术实现的难度。

随着业务领域的知识体系的庞大和复杂，业务处理逻辑或业务规则业随之复杂、难于理解、难于清晰的表达等，并且其中夹杂的大量信息与软件需要解决的问题无关。所以，在复杂系统设计方面存在如下主要问题：

规模造就的复杂度：随着需求的变化，系统规模会不断扩张，软件复杂度也不断增长，除了需求功能本身的增加，还有功能之间的联系变的牵一发而动全身，并且这个复杂度的增长往往是指数级的趋势，这样造成了软件相关人员需要掌握大量信息，提升自己对业务需求和软件的理解。

结构造就的复杂度：为了满足非功能性质量需求，例如高性能，高并发和高可靠性，在系统中引入缓存、并发处理、异步消息、海量数据的分布式存储和高效分布式计算等让系统在结构上变得复杂；为了保持系统有序，提高代码可维护性，利用分层架构达到不同层次职责分离，设计的方案在架构上带来了沟通成本的增加和管理上的困难；为了降低业务复杂度，拆分不同的子领域，往往因守不住领域的边界而丧失了拆分的价值，系统结构会变的越来越混乱，会让软件的修改变得不确定。

变化造就的复杂度：在设计软件系统时，设计人员是无法完全预测系统的变化，一方面可能过于考虑变化的影响，过度的设计付出的成本就是浪费，另一方面，如果不对变化做任何的预测，又因不停的变化而不断的付出较大研发成本。

培训对象

研发总监、研发经理/项目经理/技术经理/产品经理、系统工程师、软件研发程序员和工程师、产品规划专员。

课程收益

面对大型复杂业务系统设计思想和设计理念的提升；

传统的软件系统设计分析方法（OOA/OOD）的优点和存在的问题；

领域驱动设计的重点和难点，以及它解决问题的方法和过程；

从领域问题到领域解决方案，全过程每个节点步骤的思想和方法；

领域驱动设计中，上下文切分的思路，微服务关键问题的思考；

领域驱动建模中，从分析建模→设计建模→实现建模的技术手段和思路。

详细课程大纲

4.1 领域驱动设计--历史背景

当前软件系统开发面对的难题：系统需求的不确定性和易变性，以及系统的复杂性。

⑴   当前存在的问题是什么？

系统的复杂性：问题的复杂性、实现的灵活性、行为描述的随意性和管理开发过程的困难性；

⑵   领域驱动设计的目标是什么？

软件复杂性的应对之道：大型复杂业务系统分而治之的思想！

l  规模--通过分而治之控制规模；

l  结构--通过边界保持清晰有序；

l  变化--顺应变化方向。

⑶   领域驱动设计的方法是什么？

领域驱动设计的策略：大型复杂业务系统的领域建模方法体系！

l  规模--以子领域、限界上下文对问题空间与解空间分而治之；

l  结构--以分层架构隔离业务复杂度与技术复杂度，形成清晰的架构；

l  变化--经领域抽象，以聚合为核心的领域建模，响应需求变化。

4.2 领域驱动设计--设计思想

讲述领域驱动设计基本概念、主要内容、设计思想和设计过程，准确领悟领域驱动的战略设计和战术设计的内容及关系。

⑴   领域驱动的概念、历史根源和智慧；

⑵   领域驱动的问题和步骤（六个问题和六个步骤）；

⑶   领域模型的概念和主要思想；

⑷   领域驱动设计的主要内容和过程；

⑸   准确领悟领域驱动的战略设计和战术设计，以及战略和战术的关系。

4.3 领域驱动设计--全局分析

全局分析的目标就是确定问题空间，在统一语言的指导下，通过各种可视化手段，由领域专家与团队一起完成对问题空间的探索，帮助领域驱动设计对准问题，输出价值需求和业务需求。

价值需求既是目标系统的目标，也是对目标系统问题空间的界定和约束，它指导着业务需求分析。

业务需求由动态的业务流程和静态的业务活动组成，二者的结合依靠业务场景按照时间点和业务目标对业务流程的切分。

通过运用商业模式画布，可以获得组成价值需求的利益相关者、系统愿景和系统范围。

业务流程梳理可以帮助团队对问题空间的各条业务线构成一个整体认识，弄清楚各种角色如何参与到一个完整的流程中，流程的时序性也可以避免识别业务活动时可能出现的缺失。

业务流程图与服务蓝图以可视化的方式形象地呈现每一个提供了业务价值的业务流程。

业务活动是角色与目标系统之间的一次功能性交互，是体现了服务价值的功能行为。

一直以来，该如何确定业务需求层次，划分业务需求粒度，总是众说纷纭，没有一个客观的标准；业务活动将目标系统视为一个黑盒子，从功能性交互的完整性保证了每个业务活动都是正交的，就无需再考虑业务活动的层次和粒度，或者说，只要确定了完整性，保障了正交性，业务活动的层次与粒度也就确定下来了。

业务活动可以使用用例、用户故事或事件风暴中的事件来表达。

业务活动是全局分析阶段的基本业务单元，它的输出对于架构映射与领域建模具有重要意义：

架构映射：业务活动是识别限界上下文、确定上下文映射的基础，同时，它的粒度正好对应每个限界上下文向外公开的服务契约；

领域模型：业务需求分析细化的业务活动既是领域分析建模的重要参考，同时又作为服务场景成为场景驱动设计的起点。

全局分析是领域驱动设计统一过程的起点，它的目的是探索问题空间，使团队就问题空间的价值需求和业务需求达成共识，并在统一语言的指导下将其清晰地呈现出来。只有问题定义清楚了，团队才能更好地寻求解决方案。

4.4 领域驱动设计--架构映射

⑴  软件架构及映射概念

介绍软件架构的概念定义。

软件架构模式：

MVC架构、分层架构、DCI架构、CQRS架构、微服务分布式架构等。

架构映射

架构映射成为获得架构设计的主要设计手段。价值需求的利益相关者、系统愿景和系统范围可映射系统上下文；业务服务的归类和归纳可映射为限界上下文，系统上下文与限界上下文共同组成系统架构的重要层次，前者勾勒出解空间的控制边界，后者勾勒出领域模型的知识边界，组成了一个稳定而又具有演进能力的领域驱动架构。

系统上下文

系统上下文：以目标系统为核心，勾勒出用户、目标系统和伴生系统之间的关系。

系统上下文的确定

价值需求的中利益相关者可以充当系统上下文的用户。

系统的范围可以帮助界定系统解空间的边界，划分目标系统和伴生系统。

结合系统愿景进行判断，与愿景不相匹配的功能和业务不考虑。

限界上下文

限界上下文是领域驱动设计中最难解析的原则，但也是最重要的原则。可以说，没有限界上下文，就不能做好领域驱动设计。

对复杂系统进行分析或者综合时可以运用的方法：自顶向下和自底向上。

限界上下文识别的步骤：分析和归纳

业务知识的归类

业务知识的归纳

业务主体的边界梳理

呈现限界上下文

上下文映射

领域驱动设计强调通过深入理解业务领域，将业务模型从业务专家的角度抽象出来。然后，在应用中贯穿地使用这些模型，使开发人员和业务专家能够更好地协同合作。

通过问题空间到解空间获得业务维度的限界上下文，同时还要确定上下文与业务服务之间的映射关系，这对设计服务契约是限界文之间的协作关系，在领域分析建模时确定领域模型与限界上下文的关系。

上下文映射图的可视化呈现只是一种形式，重要是限界上下文的协作模式，它们组成上下文映射模型。限界上下文之间的映射模式：客户方/供应方、遵奉者、合作关系、共享内核、防腐层、开放主机服务、发布语言、分离方式、大泥球模式。

⑸  服务契约设计

服务契约：在全局分析阶段输出的业务需求称之为业务服务，业务服务满足了角色的服务请求，在解空间体现为服务与客户的协作关系，形成的协作接口可称之契约。

服务契约：消息契约、服务资源契约、服务行为契约、服务事件契约。

应用服务与领域服务之间：领域层与应用界面之间引入应用层，应用层尽量简单，不包含业务规则或者知识，只为领域层中的领域对象协调任务，分配工作，使它们互相协作；简单理解：“应用层只负责提问，不负责回答；领域层永远只负责回答。”应用层定义的应用服务是外观模式的体现。

⑹  领域驱动架构

领域驱动架构是针对领域驱动设计的一种架构风格。它以领域为核心驱动力，以业务能力为核心关注点，建立目标系统的结构解决方案。其核心模型为系统上下文与限界上下文，并以它们为边界，形成各自的架构模式：系统分层架构和菱形架构模式。

领域驱动架构：领域驱动设计建立的一种架构风格。

以领域为核心驱动力，以业务能力为核心关注点，建立目标系统解决方案。

领域模型为驱动的核心关注点进行纵向切分自治单元。

核心元模型以系统上下文与限界上下文为边界，形成各自架构模式：分层架构和菱形对称架构。

限界上下文是架构映射阶段的基本单元，每个限界上下文是一个自治的独立王国（微服务）。

4.5 领域驱动设计--领域建模

领域建模的过程是模型驱动设计的过程，领域建模的分析、设计和实现是循序渐进的增量和迭代的过程。

利用抽象化繁为简，通过标准的结构来组织和传递信息，形成可推演的解决方案。

解决信息超载问题的工具，对知识进行了选择性的简化和有意的结构化。

模型的重要性并不体现在它表现形式，重要是在于它传递的知识。

⑴  模型驱动设计

模型驱动设计就是把产品需求转化成一个可以运行的系统，涉及产品设计、领域建模、架构设计、详细设计、代码编写、测试等步骤。DDD的基本过程进一步展开来说，大体是以下三点：

在理解产品需求的基础上，从中提取出核心概念，然后建立起核心概念的逻辑结构，概念的逻辑结构即领域模型，领域模型以一种抽象的视角来理解复杂业务，但也仅仅是理解业务。

有了领域模型，也有了系统架构，到了这一步通常还不能直接开始编码，一般会对系统架构中的各个模块进行详细，比如模块的流程是什么，数据结构怎么设计、DB数据表怎么设计等。

要用代码搭建起一套可运行的系统。从领域模型到代码，通常不能一步跨越，中间需要通过系统架构来衔接。把领域模型映射为系统架构，这是至关重要的一步。简单来说，一般都采用分层微服务架构，架构映射即是把领域模型中的概念分解到架构中的各层。

领域分析建模

对于一个复杂的软件系统，必须对问题系统展开分析，有的放矢这对软件系统需求寻求设计上的解决方案。在战略设计阶段采用“全局分析”和“架构映射”，在战术层面，领域驱动设计要求分析方法就是要以“领域”为中心展开分析建模，获得领域分析模型。这个过程是以领域专家主导，与开发团队一起共同进行分析建模，以战略分析为基础（系统上下文和限界上下文），再进行战术设计（领域分析模型）。

领域驱动设计的关键是采取合理的方式对领域进行建模，也就是将物理世界的业务映射到软件系统产品中，最终使得软件产品能够承载实际的业务。可以从如下几个方面来进行领域建模：

⑶  领域设计建模

领域设计建模：它的核心工作就是设计聚合和设计服务，最关键的设计要素（实体、值对象、领域服务、领域事件、聚合、工厂、资源库）。领域驱动设计从不忽略技术因素对模型的影响，它引入战术层面设计元模型，将技术与领域模型结合，避免空谈对象模型的理想。

领域设计模型：只能由实体、值对象、领域服务和领域事件表示模型，避免将领域逻辑泄漏到领域层外的其它地方。

聚合用于封装实体和值对象，并维持自己边界内所有对象的完整性。

要访问聚合，只能通过聚合根的资源库，这就隐式地划定了边界和入口，有效控制了聚合内所有类型的领域对象；

若聚合创建的逻辑较为复杂或存在可变性，可引入工厂来创建聚合内的领域对象。

若牵涉到实体的状态变更，领域源模型建议通过领域事件来驱动。

设计框架总体结构采用领域驱动设计的分层架构，但不同的是该结构严格遵循分层架构的基本原则，不允许用户界面层越过应用层直接接触领域层。由于领域层是领域驱动设计的核心，而其它层经常在各类分层架构中出现，已经有了比较成熟的设计方法。因此，分层架构框架主要讨论领域层以及与领域层密切 相关的数据访问模块的设计。领域层是根据不同实际领域，利用统一编码规则实现的动态结构，又可分为聚合模块、工厂模块和仓储模块三部分。数据访问模块属于基础结构层，是封装好的静态模块。

领域实现建模

代码架构分层是经典领域驱动设计的四层：用户接口层，应用层，领域层和基础设施层。

用户接口层：面向前端用户提供服务和数据适配。这一层聚集了接口和数据适配相关的功能。

应用层：实现服务组合与编排，主要适应业务流程快速变化的需求。这一层聚集了应用服务和时间订阅相关的功能。

领域层：实现领域模型的聚合、聚合根、实体、值对象、领域服务和领域事件对象的协同和组合形成领域模型的核心业务能力。

基础设施层：它贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。

4.6 领域驱动设计--案例分析

展示和讲解5个项目案例

授课讲师介绍：

曾老师：高级工程师，毕业于武汉大学计算机系，从事计算机软件研发管理工作30余年。曾在项目经理、产品经理、研发部门经理及产品总监岗位有过多年的工作经验。曾是中国水力发电工程学会电力系统自动化专业委员会第三届和第四届委员，中国能源研究会高级会员。现在一直从事电力系统计算机应用软件系统的研发与管理工作，主持和参与过省部级科技项目4项，地市级科技项目3项，以及多项公司级的重点项目和产品。获得新产品技术鉴定国际领先科技成果1项，发表学术论文13篇，专利成果22项（发明13项、实用新型6项、外观3项），软件著作权5项。获2005年珠海市科技进步一等奖和2021年珠海市科技进步二等奖、2014年授予珠海市软件创新人才和2016年珠海市香洲区C类高端产业人才、主持研发的《XX-XXXX发电企业现场作业安全管控系统》获2021年全国智慧风电科技成果优秀奖等。

主讲的课程：软件研发培训课程四部曲

课程一：《基于AI大模型软件研发思想与技术》

——软件研发智能化的新纪元！

课程二：《软件需求工程实践及方法》

——软件研发成功的技术保障！

课程三：《领域驱动设计与实践》

——软件核心复杂性解决之道！

课程四：《软件产品平台及CBB技术》

——软件研发效率质量的利器！

主要工作经历：

1990年7月～1998年11月，云南以礼河发电厂计算机室，曾担任计算室负责人；

1998年12月～1999年11月，珠海泰坦能源电子技术有限公司，曾担任项目经理；

1999年12月～2004年4月，珠海远方软件有限公司，曾担任项目经理和研发部经理；

2004年5月～现在，在XXX公司，曾担任项目经理、产品经理和产品总监，现为产品顾问。

重点项目经历/经验

广东省科技项目《XX-XXXX配电网防误综合操作系统》，粤科计字[2008]144号

广东省教育部产学研科技项目《配电网智能防误综合操作系统》，粤财教[2010]303号

广东省科技项目《车辆段检修作业安全联锁管理系统》，粤科规财[2016]48号

广东省科技项目《基于物联网技术的电力操作系统和设备巡检系统》，粤科规划字[2012]98号

珠海市产学研项目《基于数字孪生技术的电厂作业安全智能管控系统研发及产业化》

珠海市战略性新兴产业重大项目《变电站辅助监控系统》，珠科工信[2014]160号

珠海市战略性新兴产业重大项目《基于IP通信网络的智能电网协调控制系统研发及产业化》

公司级项目《XX-XXXX发电企业现场作业安全管控系统》鉴定为“国际领先水平”，获珠海科技进步二等奖

公司级项目《XX-XXXX操作票专家系统》，获珠海市科学技术进步一等奖

公司级项目《XX-XXXX工作票专家系统》

公司级项目《XX-XXXX设备巡检系统》

我要报名没有找到合适的课程,请在这里提交您的培训需求   发布需求

主题

上课时间

2026年04月17-18日 深圳2026年07月31-01日 深圳2026年10月30-31日 深圳

参加人数

费用

联系人

先生 女士

单位名称

部门职务

电话

传真

手机

邮箱

通信地址

邮编

备注

验证码

看不清，请换一张

现在报名

推荐课程