课程费用

5800.00 /人

课程时长

2

课程排期

 
2019.09.21 -2019.09.22
北京
成为教练

课程简介

领域驱动设计

目标收益

需求分析人员和领域专家无法与团队的设计人员和开发人员进行有效沟通。需求分析人员不了解软件设计,软件设计人员常常会曲解需求内容,这是软件开发中容易出现的第一病症。它带来的后果是设计频繁变更,设计的软件不满足客户需求。
需求分析虽然明白无误,设计人员却无法准确地抽象领域模型,从而不能开展有效的软件设计,这是软件开发中容易出现的第二病症。它带来的后果是设计质量糟糕,开发的代码不具有良好的可读性,增加了软件的开发与维护成本。
系统的业务需求复杂多变,设计人员却总是喜欢从实现角度以及数据库层面思考业务问题,这是软件开发中容易出现的第三病症。它会导致开发的系统过于复杂,且可扩展性差,无法有效应对需求发

培训对象

课程大纲

第一单元
为什么需要领域建模
1、领域建模与设计的关系
优秀的软件系统与好的软件设计息息相关,但最关键的还是在于对需求的理解。如果不能正确的理解软件需求,那么再好的设计也不能设计出好的软件。正确的做事情固然重要,更重要的是要做正确的事。然而,需求到设计存在巨大的鸿沟,因为需求是站在业务角度来考虑,而设计往往会站在实现角度。领域建模就是为这二者搭建一个沟通与转换的桥梁。
本部分对比了用例驱动设计、ICONIX以及领域驱动设计,说明它们之间的关系、运用场景和区别。
第二单元
领域驱动设计的战略设计
1、通用语言(Ubiquitous Language)
为了更好的理解需求,我们需要与领域专家一起梳理目标领域的通用语言,从而就领域术语达成一致,并有利于领域建模。本部分将给出实例来说明通用语言对模型以及代码的影响。
2、限界上下文(Bounded Context)
若要进行领域建模,并将业务需求逐步演化为架构设计,则需要引入DDD(领域驱动设计)的战略设计作为指导。场景图与限界上下文可以很好地结合,帮助架构师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想识别出整个系统的业务逻辑边界与物理边界。
3、场景驱动
场景驱动设计的核心在于识别场景,它需要设计者结合具体的业务场景,分析业务流程,以此驱动出用例;再以用例驱动对业务逻辑的建模。场景驱动设计的核心模型为6W模型,即Who,Why,When,What,Where与hoW。它将对应职责模型的业务价值、业务功能与业务实现,并从角色的角度思考对象之间的协作以及设计边界。
4、通过用例识别Bounded Context
通过利用传统的用例方法来帮助我们驱动出领域的限界上下文。
可视化演练:识别EAS的限界上下文
5、Bounded Context与微服务之间的关系
通过Bounded Context,可以让DDD与微服务之间建立一种对应关系,即将BC视为独立进化部署的微服务边界。本部分将通过实例深入探讨BC的边界问题,并拓宽讲解微服务的设计。
6、上下文映射图 (Context Map)
本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式,这其中包括防腐层,开放服务调用等。利用上下文映射图,有助于识别上下文之间的关系,思考处于上下文内领域模型之间的通信方式,从而帮助架构师驱动出最终的应用逻辑架构。
7、可视化演练:EAS的应用逻辑架构

第三单元
领域驱动设计的架构设计
1、分层架构 (Layered Architecture)
分层架构模式是应用最为广泛的架构模式,它根据关注点分离的架构原则,针对表现层、领域层和基础设施层进行层次分离。本次培训将以全新视角审视分层架构,针对大型软件系统分析该如何进行分层架构设计。
案例分析:网上银行的分层架构,根据最基本的业务流程对系统进行关注点分离,绘制系统的分层架构,并通过时序图展现各层之间的协作。
2、六边形架构 (Hexagonal Architecture)
虽然分层架构仍然是运用最为广泛的架构模式,同时更是诸多架构模式的基础,但它已不足以描述越来越复杂的分布式系统架构。由Cockburn提出的六边形架构(Hexagonal Architecture)是一种具有对称性特征的架构风格。在这种架构中,不同的客户通过“平等”的方式与系统交互。该架构中存在两个区域,分别是“外部区域”和“内部区域”。这种界定了明确内外边界的架构风格,更有利于架构师实现关注点分离,并将关注重心放在适配器与通信端口上。
演练:六边形架构的通信边界
3、CQRS
CQRS风格,即命令查询职责分离(Command Query Responsibility Segregation),它结合了消息处理、事件处理的架构风格,是对多种设计模式的综合运用,适用于处理读写比例高,需要支持可伸缩性的大型系统。
4、事件驱动架构 (Event-Driven Architecture)
事件驱动架构(Event-Driven Architecture,EDA)是一种用于处理事件生成、发现和处理等任务的软件架构。事件往往对应于软件系统的状态机,状态的迁移就是用事件来触发的。因而,事件能够很好地体现这样的业务模型。同时,基于事件的软件架构可以帮助我们更好地建立松散耦合的模块化架构。
第四单元
领域驱动设计的战术设计
1、领域模型
通过限界上下文,可以帮助我们分析系统的领域模型,包括系统的核心领域与子领域。确定系统的核心领域与子领域可以帮助架构师合理分配资源(包括时间资源与人力资源)。而对子领域的进一步识别,可以帮助架构师更好地识别可重用资源,包括可重用的功能模块,确定技术栈,决定构建还是购买的架构战略。
2、四色建模法
首先以满足管理和运营的需要为前提,寻找需要追溯的事件。根据这些需要追溯,寻找足迹以及相应的时标性对象。寻找时标对象周围的人/事/物。从中抽象角色,把一些信息用描述对象补足。
案例分析:配送管理系统的四色建模
3、实体(Entity)与值对象(Value Object)
这两个概念都是领域对象的体现,二者的主要区别在于对“标识”的运用。本部分的内容深入展开对实体标识的讨论,揭示实体的本质特征,挖掘实体的关键行为。通过识别角色与职责对实现进行分析。
本部分内容还将通过深入讲解值对象的特征帮助我们分辨值对象与实体,使得我们可以在领域驱动设计中有效地运用实体与值对象。本部分内容还包括持久化值对象,以及领域驱动设计与ORM之间的关系。
4、领域服务 (Domain Service)
通过讲解什么是领域服务,什么不是领域服务理清领域服务的概念,并讲解如何建模领域服务。讨论领域服务和面向接口设计思想。
5、领域事件 (Domain Event)
事件驱动架构的主要对象即为领域事件,我们要分清在何时以及为什么要使用领域事件,并对领域事件进行建模。通过讲解发布者-订阅者模式讲解如何在领域模型和限界上下文中发布领域事件。同时,针对事件进行存储的Event Source也与CQRS架构风格直接相关。
演练:寻找领域事件
6、聚合 (Aggregation)
聚合是领域驱动设计最为重要的领域概念。本部分内容将深入探讨聚合的设计原则,并辨别在聚合设计中可能出现的坏味道,并提出针对性的解决方案。这些原则和方案包括:在一致性边界之内建模真正的不变量,设计小的聚合,通过唯一标识引用其他聚合,在边界外满足最终一致性。
7、工厂(Factory)和资源库(Repository)
工厂和资源库都是管理领域对象(实体、值对象和服务)生命周期的对象。工厂主要针对内存中对象从无到有的创建过程,与设计模式的工厂模式基本相似。
资源库则分为面向集合的资源库与面向持久化的资源库。本部分内容将重点讲解与资源库直接相关的技术细节,包括如何选择资源库的方式,如何针对聚合持久化资源库,如何管理事务,以及分辨资源库与数据访问对象(DAO)之间的异同。
8、应用层(Application Layer)设计
作为为UI提供的应用服务,其目的在于管理和协调领域对象,并为领域对象提供横切关注点的内容。好的应用服务设计不应该承担任何与领域逻辑有关的职责。应用层是架构层面的外观与适配器模式的体现。它可以提高软件系统架构的可用性与简单性,也能够更好地与面向服务架构或RESTful架构风格结合。
9、时序图
根据事先识别的Use Case,为其绘制时序图,动态地寻找Application Service到各种领域对象之间的协作,以帮助我们寻找到遗漏的领域对象与设计对象。
第五单元
DDD专题讨论
专题一:贫血模型
Transaction Script与Domain Model之争
贫血模型与充血模型之争
Service废存的争论
专题二:DCI
DCI是领域驱动设计的一个分支,更加关注系统的行为,从而提高代码的可读性。该范式将Data Model(data)从Use Cases(context)以及对象扮演的Role(Interaction)中分离出来。
第六单元
DDD实战演练
1、项目需求:
企业应用套件(EAS)系统是一个根据某集团应用信息化的要求而开发的企业级应用软件。本系统为用户提供大量简单,快捷的操作接口,集团相关部门能更快捷、更方便、更高效地处理日常事务工作,并为管理者提供决策参考、流程简化,建立集团与各部门、员工之间交流的通道,有效地提高工作效率,实现整个集团的信息化管理。
2、项目目标
实现集团企业应用信息化,包括人力资源信息管理、项目管理、客户关系管理等。具体目标如下:
* 实现集团日常事务的信息化管理,包括工作日志、考勤、月度工作评价等;
* 解决客户业务需求与集团人员供应之间的矛盾,实现供需平衡,建立沟通的有效通道;
* 实现项目的信息化管理,包括项目开发流程管理、项目人员信息跟踪、统计项目信息等;
* 提供市场信息、人员信息、项目信息的统计,辅助管理者作出正确的决策。
3、项目要解决的问题:
* 公司市场信息、人员信息不畅通,无法实现人员供需平衡:“供”主要表现在各公司富余人员信息、项目中快结束人员信息、人员招聘信息、学院培训人员信息等不能有效反馈。“需”主要表现在已签约项目人员需求、意向项目人员需求、公司计划人员需求等信息无法及时传递。“供”“需”脱节,信息不畅,不能快速有效的进行供需求匹配。
* 公司各项配套管理问题。各职能部门不能及时获得“供需”信息,也就无法及时对设备、住房、工位、资金进行配套协调管理。
* 辅助决策管理问题。公司领导决策层不能很好的把握全局,无法有侧重的进行资源协调及工作支持,包括市场力度、人才管理、财务政策及公司日常管理。
* 客户信息共享及项目管理质量控制问题。无法跟踪项目人员的工作状态,可能导致项目组成员以及项目质量的失控。
这是领域驱动设计过程的完整案例分析,从需求开始着手,开展对整个系统的架构分析、领域概念识别与分析,并对建立的领域模型进行迭代与演化,核心领域概念的演进,扫清领域设计过程中的认知障碍,并总结了领域驱动设计过程的一些经验教训。
本实战演练包含了真实的案例需求,以及符合领域驱动设计各种知识点的案例病症分析,从对比入手来探讨好的领域驱动设计方法。同时,还将引入大量的可视化图形、设计图与代码帮助学员理解如何在真实项目中运用领域驱动设计的思想,指导设计人员进行良好的设计。

第一单元
为什么需要领域建模
1、领域建模与设计的关系
优秀的软件系统与好的软件设计息息相关,但最关键的还是在于对需求的理解。如果不能正确的理解软件需求,那么再好的设计也不能设计出好的软件。正确的做事情固然重要,更重要的是要做正确的事。然而,需求到设计存在巨大的鸿沟,因为需求是站在业务角度来考虑,而设计往往会站在实现角度。领域建模就是为这二者搭建一个沟通与转换的桥梁。
本部分对比了用例驱动设计、ICONIX以及领域驱动设计,说明它们之间的关系、运用场景和区别。
第二单元
领域驱动设计的战略设计
1、通用语言(Ubiquitous Language)
为了更好的理解需求,我们需要与领域专家一起梳理目标领域的通用语言,从而就领域术语达成一致,并有利于领域建模。本部分将给出实例来说明通用语言对模型以及代码的影响。
2、限界上下文(Bounded Context)
若要进行领域建模,并将业务需求逐步演化为架构设计,则需要引入DDD(领域驱动设计)的战略设计作为指导。场景图与限界上下文可以很好地结合,帮助架构师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想识别出整个系统的业务逻辑边界与物理边界。
3、场景驱动
场景驱动设计的核心在于识别场景,它需要设计者结合具体的业务场景,分析业务流程,以此驱动出用例;再以用例驱动对业务逻辑的建模。场景驱动设计的核心模型为6W模型,即Who,Why,When,What,Where与hoW。它将对应职责模型的业务价值、业务功能与业务实现,并从角色的角度思考对象之间的协作以及设计边界。
4、通过用例识别Bounded Context
通过利用传统的用例方法来帮助我们驱动出领域的限界上下文。
可视化演练:识别EAS的限界上下文
5、Bounded Context与微服务之间的关系
通过Bounded Context,可以让DDD与微服务之间建立一种对应关系,即将BC视为独立进化部署的微服务边界。本部分将通过实例深入探讨BC的边界问题,并拓宽讲解微服务的设计。
6、上下文映射图 (Context Map)
本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式,这其中包括防腐层,开放服务调用等。利用上下文映射图,有助于识别上下文之间的关系,思考处于上下文内领域模型之间的通信方式,从而帮助架构师驱动出最终的应用逻辑架构。
7、可视化演练:EAS的应用逻辑架构

第三单元
领域驱动设计的架构设计
1、分层架构 (Layered Architecture)
分层架构模式是应用最为广泛的架构模式,它根据关注点分离的架构原则,针对表现层、领域层和基础设施层进行层次分离。本次培训将以全新视角审视分层架构,针对大型软件系统分析该如何进行分层架构设计。
案例分析:网上银行的分层架构,根据最基本的业务流程对系统进行关注点分离,绘制系统的分层架构,并通过时序图展现各层之间的协作。
2、六边形架构 (Hexagonal Architecture)
虽然分层架构仍然是运用最为广泛的架构模式,同时更是诸多架构模式的基础,但它已不足以描述越来越复杂的分布式系统架构。由Cockburn提出的六边形架构(Hexagonal Architecture)是一种具有对称性特征的架构风格。在这种架构中,不同的客户通过“平等”的方式与系统交互。该架构中存在两个区域,分别是“外部区域”和“内部区域”。这种界定了明确内外边界的架构风格,更有利于架构师实现关注点分离,并将关注重心放在适配器与通信端口上。
演练:六边形架构的通信边界
3、CQRS
CQRS风格,即命令查询职责分离(Command Query Responsibility Segregation),它结合了消息处理、事件处理的架构风格,是对多种设计模式的综合运用,适用于处理读写比例高,需要支持可伸缩性的大型系统。
4、事件驱动架构 (Event-Driven Architecture)
事件驱动架构(Event-Driven Architecture,EDA)是一种用于处理事件生成、发现和处理等任务的软件架构。事件往往对应于软件系统的状态机,状态的迁移就是用事件来触发的。因而,事件能够很好地体现这样的业务模型。同时,基于事件的软件架构可以帮助我们更好地建立松散耦合的模块化架构。
第四单元
领域驱动设计的战术设计
1、领域模型
通过限界上下文,可以帮助我们分析系统的领域模型,包括系统的核心领域与子领域。确定系统的核心领域与子领域可以帮助架构师合理分配资源(包括时间资源与人力资源)。而对子领域的进一步识别,可以帮助架构师更好地识别可重用资源,包括可重用的功能模块,确定技术栈,决定构建还是购买的架构战略。
2、四色建模法
首先以满足管理和运营的需要为前提,寻找需要追溯的事件。根据这些需要追溯,寻找足迹以及相应的时标性对象。寻找时标对象周围的人/事/物。从中抽象角色,把一些信息用描述对象补足。
案例分析:配送管理系统的四色建模
3、实体(Entity)与值对象(Value Object)
这两个概念都是领域对象的体现,二者的主要区别在于对“标识”的运用。本部分的内容深入展开对实体标识的讨论,揭示实体的本质特征,挖掘实体的关键行为。通过识别角色与职责对实现进行分析。
本部分内容还将通过深入讲解值对象的特征帮助我们分辨值对象与实体,使得我们可以在领域驱动设计中有效地运用实体与值对象。本部分内容还包括持久化值对象,以及领域驱动设计与ORM之间的关系。
4、领域服务 (Domain Service)
通过讲解什么是领域服务,什么不是领域服务理清领域服务的概念,并讲解如何建模领域服务。讨论领域服务和面向接口设计思想。
5、领域事件 (Domain Event)
事件驱动架构的主要对象即为领域事件,我们要分清在何时以及为什么要使用领域事件,并对领域事件进行建模。通过讲解发布者-订阅者模式讲解如何在领域模型和限界上下文中发布领域事件。同时,针对事件进行存储的Event Source也与CQRS架构风格直接相关。
演练:寻找领域事件
6、聚合 (Aggregation)
聚合是领域驱动设计最为重要的领域概念。本部分内容将深入探讨聚合的设计原则,并辨别在聚合设计中可能出现的坏味道,并提出针对性的解决方案。这些原则和方案包括:在一致性边界之内建模真正的不变量,设计小的聚合,通过唯一标识引用其他聚合,在边界外满足最终一致性。
7、工厂(Factory)和资源库(Repository)
工厂和资源库都是管理领域对象(实体、值对象和服务)生命周期的对象。工厂主要针对内存中对象从无到有的创建过程,与设计模式的工厂模式基本相似。
资源库则分为面向集合的资源库与面向持久化的资源库。本部分内容将重点讲解与资源库直接相关的技术细节,包括如何选择资源库的方式,如何针对聚合持久化资源库,如何管理事务,以及分辨资源库与数据访问对象(DAO)之间的异同。
8、应用层(Application Layer)设计
作为为UI提供的应用服务,其目的在于管理和协调领域对象,并为领域对象提供横切关注点的内容。好的应用服务设计不应该承担任何与领域逻辑有关的职责。应用层是架构层面的外观与适配器模式的体现。它可以提高软件系统架构的可用性与简单性,也能够更好地与面向服务架构或RESTful架构风格结合。
9、时序图
根据事先识别的Use Case,为其绘制时序图,动态地寻找Application Service到各种领域对象之间的协作,以帮助我们寻找到遗漏的领域对象与设计对象。
第五单元
DDD专题讨论
专题一:贫血模型
Transaction Script与Domain Model之争
贫血模型与充血模型之争
Service废存的争论
专题二:DCI
DCI是领域驱动设计的一个分支,更加关注系统的行为,从而提高代码的可读性。该范式将Data Model(data)从Use Cases(context)以及对象扮演的Role(Interaction)中分离出来。
第六单元
DDD实战演练
1、项目需求:
企业应用套件(EAS)系统是一个根据某集团应用信息化的要求而开发的企业级应用软件。本系统为用户提供大量简单,快捷的操作接口,集团相关部门能更快捷、更方便、更高效地处理日常事务工作,并为管理者提供决策参考、流程简化,建立集团与各部门、员工之间交流的通道,有效地提高工作效率,实现整个集团的信息化管理。
2、项目目标
实现集团企业应用信息化,包括人力资源信息管理、项目管理、客户关系管理等。具体目标如下:
* 实现集团日常事务的信息化管理,包括工作日志、考勤、月度工作评价等;
* 解决客户业务需求与集团人员供应之间的矛盾,实现供需平衡,建立沟通的有效通道;
* 实现项目的信息化管理,包括项目开发流程管理、项目人员信息跟踪、统计项目信息等;
* 提供市场信息、人员信息、项目信息的统计,辅助管理者作出正确的决策。
3、项目要解决的问题:
* 公司市场信息、人员信息不畅通,无法实现人员供需平衡:“供”主要表现在各公司富余人员信息、项目中快结束人员信息、人员招聘信息、学院培训人员信息等不能有效反馈。“需”主要表现在已签约项目人员需求、意向项目人员需求、公司计划人员需求等信息无法及时传递。“供”“需”脱节,信息不畅,不能快速有效的进行供需求匹配。
* 公司各项配套管理问题。各职能部门不能及时获得“供需”信息,也就无法及时对设备、住房、工位、资金进行配套协调管理。
* 辅助决策管理问题。公司领导决策层不能很好的把握全局,无法有侧重的进行资源协调及工作支持,包括市场力度、人才管理、财务政策及公司日常管理。
* 客户信息共享及项目管理质量控制问题。无法跟踪项目人员的工作状态,可能导致项目组成员以及项目质量的失控。
这是领域驱动设计过程的完整案例分析,从需求开始着手,开展对整个系统的架构分析、领域概念识别与分析,并对建立的领域模型进行迭代与演化,核心领域概念的演进,扫清领域设计过程中的认知障碍,并总结了领域驱动设计过程的一些经验教训。
本实战演练包含了真实的案例需求,以及符合领域驱动设计各种知识点的案例病症分析,从对比入手来探讨好的领域驱动设计方法。同时,还将引入大量的可视化图形、设计图与代码帮助学员理解如何在真实项目中运用领域驱动设计的思想,指导设计人员进行良好的设计。

课程评论

课程费用

5800.00 /人

课程时长

2

scheduling->endTime - $model->scheduling->startTime) / 86400 ) ?>

课程排期 (更新日期:2018.10.31)

2019.09.21 -2019.09.22
北京
立即报名 我要分享

近期公开课推荐

近期公开课推荐