领域驱动设计

架构设计 / 2020-04-26 10:20:17
领域驱动设计
    马上咨询

    张逸  现為(wèi)深圳大眼科(kē)技有(yǒu)限公司的首席架构师，联合创始人 

    先后就职于中兴通讯、惠普GDCC、中软國(guó)际、ThoughtWorks等大型中外企业，任职角色為(wèi)高级软件工程师，架构师，技术总监，首席咨询师。精通包括C#、Java、Ruby、Scala、Python、JavaScript等多(duō)种语言，熟练掌握面向对象思想、领域驱动设计、函数式语言、架构、大数据分(fēn)析、敏捷与过程改进，并致力于大型软件企业的面向服務(wù)系统架构设计以及互联网Web系统架构设计。在ThoughtWorks期间，作為(wèi)一名咨询师，主要為(wèi)客户提供组织的敏捷转型、过程改进、系统架构监理(lǐ)、领域设计、代码质量提升等咨询工作。目前，作為(wèi)公司产品的架构师，致力于商(shāng)业智能(néng)产品与大数据分(fēn)析平台的开发与架构设计。

    培训特色

    • 思想為(wèi)體(tǐ)，方法為(wèi)用(yòng)，贯彻卓越软件设计之精神，而非流于表面形式；
    • 提倡开放的设计观，不局限于一种设计方法學(xué)，而是融汇贯通，取長(cháng)补短；
    • 重视案例分(fēn)析与实践，提倡动手实验，而非单纯以讲授性质的培训；通过真实案例的演练，熟悉开发过程与设计方法；
    • 采用(yòng)最新(xīn)的领域驱动设计思想与方法，并辅以可(kě)视化的设计手段，以工作坊的形式开展培训，以便于學(xué)员更好地理(lǐ)解领域驱动设计；
    • 编码与设计，二者不可(kě)偏废　

    目标收益

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

    课程大纲

    第一单元  為(wèi)什么需要领域建模（1小(xiǎo)时）
    1、领域建模与设计的关系
    优秀的软件系统与好的软件设计息息相关，但最关键的还是在于对需求的理(lǐ)解。如果不能(néng)正确的理(lǐ)解软件需求，那么再好的设计也不能(néng)设计出好的软件。正确的做事情固然重要，更重要的是要做正确的事。然而，需求到设计存在巨大的鸿沟，因為(wèi)需求是站在业務(wù)角度来考虑，而设计往往会站在实现角度。领域建模就是為(wèi)这二者搭建一个沟通与转换的桥梁。
    2、本部分(fēn)对比了用(yòng)例驱动设计、ICONIX以及领域驱动设计，说明它们之间的关系、运用(yòng)场景和區(qū)别。
    内容包括：
    • 问题域
    • 核心领域宇子领域
    • 解决方案域
    第二单元  领域驱动设计的战略设计（4小(xiǎo)时）
    1、通用(yòng)语言（Ubiquitous Language）
    為(wèi)了更好的理(lǐ)解需求，我们需要与领域专家一起梳理(lǐ)目标领域的通用(yòng)语言，从而就领域术语达成一致，并有(yǒu)利于领域建模。本部分(fēn)将给出实例来说明通用(yòng)语言对模型以及代码的影响。内容包括：
    • 获得通用(yòng)语言的方法
    • 通用(yòng)语言对编码的影响
    2、限界上下文(wén)（Bounded Context）
    若要进行领域建模，并将业務(wù)需求逐步演化為(wèi)架构设计，则需要引入DDD（领域驱动设计）的战略设计作為(wèi)指导。场景图与限界上下文(wén)可(kě)以很(hěn)好地结合，帮助架构师很(hěn)好地识别各个子领域的概念边界与设计边界。如此则可(kě)以运用(yòng)“分(fēn)而治之”的思想识别出整个系统的业務(wù)逻辑边界与物(wù)理(lǐ)边界。
    本部分(fēn)同时还讨论了诸多(duō)设计原则在Bounded Context中的运用(yòng)，探讨了Bounded Context的本质思想，强调Bounded Context的边界，进而与微服務(wù)架构结合起来，即Bounded Context的设计其实就是微服務(wù)的设计。内容包括：
    • Bounded Context意义
    • 识别Bounded Context
    • 议题：Bounded Context的边界
    3、场景驱动
    场景驱动设计的核心在于识别场景，它需要设计者结合具體(tǐ)的业務(wù)场景，分(fēn)析业務(wù)流程，以此驱动出用(yòng)例；再以用(yòng)例驱动对业務(wù)逻辑的建模。场景驱动设计的核心模型為(wèi)6W模型，即Who，Why，When，What，Where与hoW。它将对应职责模型的业務(wù)价值、业務(wù)功能(néng)与业務(wù)实现，并从角色的角度思考对象之间的协作以及设计边界。
    4、通过用(yòng)例识别Bounded Context
    • 通过利用(yòng)传统的用(yòng)例方法来帮助我们驱动出领域的限界上下文(wén)。
    • 可(kě)视化演练：识别EAS的限界上下文(wén)
    5、Bounded Context与微服務(wù)之间的关系
    通过Bounded Context，可(kě)以让DDD与微服務(wù)之间建立一种对应关系，即将BC视為(wèi)独立进化部署的微服務(wù)边界。本部分(fēn)将通过实例深入探讨BC的边界问题，并拓宽讲解微服務(wù)的设计。
    6、上下文(wén)映射图 (Context Map)
    本部分(fēn)内容会讲解限界上下文(wén)之间主要存在的组织模式与集成模式，这其中包括防腐层，开放服務(wù)调用(yòng)等。利用(yòng)上下文(wén)映射图，有(yǒu)助于识别上下文(wén)之间的关系，思考处于上下文(wén)内领域模型之间的通信方式，从而帮助架构师驱动出最终的应用(yòng)逻辑架构。内容包括：
    • 团队的组织模式
    • 集成模式
    • Context Map案例分(fēn)析
    7、可(kě)视化演练：EAS的应用(yòng)逻辑架构
    第三单元  领域驱动设计的架构设计（4小(xiǎo)时）
    1、分(fēn)层架构 (Layered   Architecture)
    分(fēn)层架构模式是应用(yòng)最為(wèi)广泛的架构模式，它根据关注点分(fēn)离的架构原则，针对表现层、领域层和基础设施层进行层次分(fēn)离。本次培训将以全新(xīn)视角审视分(fēn)层架构，针对大型软件系统分(fēn)析该如何进行分(fēn)层架构设计。内容包括：
    • DDD分(fēn)层架构模式
    • Clean Architecture思想
    • 依赖注入与贫血模型
    案例分(fēn)析：网上银行的分(fēn)层架构，根据最基本的业務(wù)流程对系统进行关注点分(fēn)离，绘制系统的分(fēn)层架构，并通过时序图展现各层之间的协作。
    2、六边形架构 (Hexagonal Architecture)
    虽然分(fēn)层架构仍然是运用(yòng)最為(wèi)广泛的架构模式，同时更是诸多(duō)架构模式的基础，但它已不足以描述越来越复杂的分(fēn)布式系统架构。由Cockburn提出的六边形架构（Hexagonal Architecture）是一种具有(yǒu)对称性特征的架构风格。在这种架构中，不同的客户通过“平等”的方式与系统交互。该架构中存在两个區(qū)域，分(fēn)别是“外部區(qū)域”和“内部區(qū)域”。这种界定了明确内外边界的架构风格，更有(yǒu)利于架构师实现关注点分(fēn)离，并将关注重心放在适配器与通信端口上。
    演练：六边形架构的通信边界
    3、CQRS
    CQRS风格，即命令查询职责分(fēn)离（Command Query Responsibility   Segregation），它结合了消息处理(lǐ)、事件处理(lǐ)的架构风格，是对多(duō)种设计模式的综合运用(yòng)，适用(yòng)于处理(lǐ)读写比例高，需要支持可(kě)伸缩性的大型系统。
    4、事件驱动架构   (Event-Driven Architecture)
    事件驱动架构（Event-Driven Architecture，EDA）是一种用(yòng)于处理(lǐ)事件生成、发现和处理(lǐ)等任務(wù)的软件架构。事件往往对应于软件系统的状态机，状态的迁移就是用(yòng)事件来触发的。因而，事件能(néng)够很(hěn)好地體(tǐ)现这样的业務(wù)模型。同时，基于事件的软件架构可(kě)以帮助我们更好地建立松散耦合的模块化架构。
    第四单元  领域驱动设计的战术设计（3小(xiǎo)时）
    1、领域模型
    通过限界上下文(wén)，可(kě)以帮助我们分(fēn)析系统的领域模型，包括系统的核心领域与子领域。确定系统的核心领域与子领域可(kě)以帮助架构师合理(lǐ)分(fēn)配资源（包括时间资源与人力资源）。而对子领域的进一步识别，可(kě)以帮助架构师更好地识别可(kě)重用(yòng)资源，包括可(kě)重用(yòng)的功能(néng)模块，确定技术栈，决定构建还是購(gòu)买的架构战略。内容包括：
    • DDD核心概念和要素要素
    • 领域建模的演进
    2、四色建模法
    首先以满足管理(lǐ)和运营的需要為(wèi)前提，寻找需要追溯的事件。根据这些需要追溯，寻找足迹以及相应的时标性对象。寻找时标对象周围的人／事／物(wù)。从中抽象角色，把一些信息用(yòng)描述对象补足。
    案例分(fēn)析：配送管理(lǐ)系统的四色建模
    3、实體(tǐ)（Entity）与值对象（Value Object）
    这两个概念都是领域对象的體(tǐ)现，二者的主要區(qū)别在于对“标识”的运用(yòng)。本部分(fēn)的内容深入展开对实體(tǐ)标识的讨论，揭示实體(tǐ)的本质特征，挖掘实體(tǐ)的关键行為(wèi)。通过识别角色与职责对实现进行分(fēn)析。
    本部分(fēn)内容还将通过深入讲解值对象的特征帮助我们分(fēn)辨值对象与实體(tǐ)，使得我们可(kě)以在领域驱动设计中有(yǒu)效地运用(yòng)实體(tǐ)与值对象。本部分(fēn)内容还包括持久化值对象，以及领域驱动设计与ORM之间的关系。内容包括：
    • 实體(tǐ)的标识别
    • 避免贫血模型
    • 角色、职责与协作
    • 领域建模与数据建模
    4、领域服務(wù) (Domain   Service)
    通过讲解什么是领域服務(wù)，什么不是领域服務(wù)理(lǐ)清领域服務(wù)的概念，并讲解如何建模领域服務(wù)。讨论领域服務(wù)和面向接口设计思想。内容包括：
    • 何时建模為(wèi)服務(wù)
    • 识别建模的坏味道
    5、领域事件 (Domain   Event)
    事件驱动架构的主要对象即為(wèi)领域事件，我们要分(fēn)清在何时以及為(wèi)什么要使用(yòng)领域事件，并对领域事件进行建模。通过讲解发布者-订阅者模式讲解如何在领域模型和限界上下文(wén)中发布领域事件。同时，针对事件进行存储的Event   Source也与CQRS架构风格直接相关。内容包括：
    • 事件的本质
    • 事件带来的价值
    • 演练：寻找领域事件
    6、聚合   (Aggregation)
    聚合是领域驱动设计最為(wèi)重要的领域概念。本部分(fēn)内容将深入探讨聚合的设计原则，并辨别在聚合设计中可(kě)能(néng)出现的坏味道，并提出针对性的解决方案。这些原则和方案包括：在一致性边界之内建模真正的不变量，设计小(xiǎo)的聚合，通过唯一标识引用(yòng)其他(tā)聚合，在边界外满足最终一致性。内容包括：
    • 聚合维护多(duō)个实體(tǐ)、值对象的边界
    • 案例研究
    • 设计聚合的原则
    7、工厂(Factory)和资源库(Repository)
    工厂和资源库都是管理(lǐ)领域对象（实體(tǐ)、值对象和服務(wù)）生命周期的对象。工厂主要针对内存中对象从无到有(yǒu)的创建过程，与设计模式的工厂模式基本相似。
    资源库则分(fēn)為(wèi)面向集合的资源库与面向持久化的资源库。本部分(fēn)内容将重点讲解与资源库直接相关的技术细节，包括如何选择资源库的方式，如何针对聚合持久化资源库，如何管理(lǐ)事務(wù)，以及分(fēn)辨资源库与数据访问对象（DAO）之间的异同。
    8、应用(yòng)层(Application   Layer)设计
    作為(wèi)為(wèi)UI提供的应用(yòng)服務(wù)，其目的在于管理(lǐ)和协调领域对象，并為(wèi)领域对象提供横切关注点的内容。好的应用(yòng)服務(wù)设计不应该承担任何与领域逻辑有(yǒu)关的职责。应用(yòng)层是架构层面的外观与适配器模式的體(tǐ)现。它可(kě)以提高软件系统架构的可(kě)用(yòng)性与简单性，也能(néng)够更好地与面向服務(wù)架构或RESTful架构风格结合。9、时序图
    根据事先识别的Use Case，為(wèi)其绘制时序图，动态地寻找Application   Service到各种领域对象之间的协作，以帮助我们寻找到遗漏的领域对象与设计对象。
    第五单元    DDD专题讨论（1小(xiǎo)时）
    专题一：贫血模型
    • Transaction Script与Domain Model之争
    • 贫血模型与充血模型之争
    • Service废存的争论
    专题二：DCI
    DCI是领域驱动设计的一个分(fēn)支，更加关注系统的行為(wèi)，从而提高代码的可(kě)读性。该范式将Data Model（data）从Use Cases(context)以及对象扮演的Role（Interaction)中分(fēn)离出来。
    第六单元   DDD实战演练（用(yòng)中移动案例实战5小(xiǎo)时）
    1、项目需求：
    企业应用(yòng)套件（EAS）系统是一个根据某集团应用(yòng)信息化的要求而开发的企业级应用(yòng)软件。本系统為(wèi)用(yòng)户提供大量简单，快捷的操作接口，集团相关部门能(néng)更快捷、更方便、更高效地处理(lǐ)日常事務(wù)工作，并為(wèi)管理(lǐ)者提供决策参考、流程简化，建立集团与各部门、员工之间交流的通道，有(yǒu)效地提高工作效率，实现整个集团的信息化管理(lǐ)。
    2、项目目标
    实现集团企业应用(yòng)信息化，包括人力资源信息管理(lǐ)、项目管理(lǐ)、客户关系管理(lǐ)等。具體(tǐ)目标如下：
    • 实现集团日常事務(wù)的信息化管理(lǐ)，包括工作日志(zhì)、考勤、月度工作评价等；
    • 解决客户业務(wù)需求与集团人员供应之间的矛盾，实现供需平衡，建立沟通的有(yǒu)效通道；
    • 实现项目的信息化管理(lǐ)，包括项目开发流程管理(lǐ)、项目人员信息跟踪、统计项目信息等；
    • 提供市场信息、人员信息、项目信息的统计，辅助管理(lǐ)者作出正确的决策。
    3、项目要解决的问题：
    • 公司市场信息、人员信息不畅通，无法实现人员供需平衡：“供”主要表现在各公司富余人员信息、项目中快结束人员信息、人员招聘信息、學(xué)院培训人员信息等不能(néng)有(yǒu)效反馈。“需”主要表现在已签约项目人员需求、意向项目人员需求、公司计划人员需求等信息无法及时传递。“供”“需”脱节，信息不畅，不能(néng)快速有(yǒu)效的进行供需求匹配。
    • 公司各项配套管理(lǐ)问题。各职能(néng)部门不能(néng)及时获得“供需”信息，也就无法及时对设备、住房、工位、资金进行配套协调管理(lǐ)。
    • 辅助决策管理(lǐ)问题。公司领导决策层不能(néng)很(hěn)好的把握全局，无法有(yǒu)侧重的进行资源协调及工作支持，包括市场力度、人才管理(lǐ)、财務(wù)政策及公司日常管理(lǐ)。
    • 客户信息共享及项目管理(lǐ)质量控制问题。无法跟踪项目人员的工作状态，可(kě)能(néng)导致项目组成员以及项目质量的失控。
    这是领域驱动设计过程的完整案例分(fēn)析，从需求开始着手，开展对整个系统的架构分(fēn)析、领域概念识别与分(fēn)析，并对建立的领域模型进行迭代与演化，核心领域概念的演进，扫清领域设计过程中的认知障碍，并总结了领域驱动设计过程的一些经验教训。
    本实战演练包含了真实的案例需求，以及符合领域驱动设计各种知识点的案例病症分(fēn)析，从对比入手来探讨好的领域驱动设计方法。同时，还将引入大量的可(kě)视化图形、设计图与代码帮助學(xué)员理(lǐ)解如何在真实项目中运用(yòng)领域驱动设计的思想，指导设计人员进行良好的设计。