领域驱动设计与系统重构以及API设计.doc

领域驱动设计与系统重构以及API设计1 培训目标需求分析人员和领域专家无法与团队的设计人员和开发人员进行有效沟通。需求分析人员不了解软件设计，软件设计人员常常会曲解需求内容，这是软件开发中容易出现的第一病症。它带来的后果是设计频繁变更，设计的软件不满足客户需求。需求分析虽然明白无误，设计人员却无法准确地抽象领域模型，从而不能开展有效的软件设计，这是软件开发中容易出现的第二病症。它带来的后果是设计质量糟糕，开发的代码不具有良好的可读性，增加了软件的开发与维护成本。系统的业务需求复杂多变，设计人员却总是喜欢从实现角度以及数据库层面思考业务问题，这是软件开发中容易出现的第三病症。它会导致开发的系统过于复杂，且可扩展性差，无法有效应对需求发生的变化。无论设计多么合理，面对需求变化时，我们都需要对现有设计进行改进。领域驱动设计可以在一定程度上保证设计的质量，而重构则可以保证在付出较小成本的前提下调整与改善设计，从而更好地满足需求变化。本次培训的内容领域驱动设计与系统重构正好是解决这三种常见病症的最佳药方。2 培训计划时间课题内容第一天（上午）第一单元领域建模的方法1、领域建模与设计的关系优秀的软件系统与好的软件设计息息相关，但最关键的还是在于对需求的理解。如果不能正确的理解软件需求，那么再好的设计也不能设计出好的软件。正确的做事情固然重要，更重要的是要做正确的事。然而，需求到设计存在巨大的鸿沟，因为需求是站在业务角度来考虑，而设计往往会站在实现角度。领域建模就是为这二者搭建一个沟通与转换的桥梁。2、统一语言（Ubiquitous Language）为了更好的理解需求，我们需要与领域专家一起梳理目标领域的统一语言，从而就领域术语达成一致，并有利于领域建模。第二单元领域驱动设计的战略设计1、限界上下文（Bounded Context）若要进行领域建模，并将业务需求逐步演化为架构设计，则需要引入DDD（领域驱动设计）的战略设计作为指导。场景图与限界上下文可以很好地结合，帮助架构师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想识别出整个系统的业务逻辑边界与物理边界。2、用例方法 (Use Case)通过利用传统的用例方法来帮助我们驱动出领域的限界上下文。可视化演练：识别电子商务系统的限界上下文3、上下文映射图 (Context Map)本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式，这其中包括防腐层，开放服务调用等。利用上下文映射图，有助于识别上下文之间的关系，思考处于上下文内领域模型之间的通信方式，从而帮助架构师驱动出最终的应用逻辑架构。可视化演练：电子商务系统的应用逻辑架构第一天（下午）第三单元领域驱动设计的架构设计1、分层架构 (Layered Architecture)分层架构模式是应用最为广泛的架构模式，它根据关注点分离的架构原则，针对表现层、领域层和基础设施层进行层次分离。本次培训将以全新视角审视分层架构，针对大型软件系统分析该如何进行分层架构设计。案例分析：网上银行的分层架构，根据最基本的业务流程对系统进行关注点分离，绘制系统的分层架构，并通过时序图展现各层之间的协作。2、六边形架构 (Hexagonal Architecture)虽然分层架构仍然是运用最为广泛的架构模式，同时更是诸多架构模式的基础，但它已不足以描述越来越复杂的分布式系统架构。由Cockburn提出的六边形架构（Hexagonal Architecture）是一种具有对称性特征的架构风格。在这种架构中，不同的客户通过“平等”的方式与系统交互。该架构中存在两个区域，分别是“外部区域”和“内部区域”。这种界定了明确内外边界的架构风格，更有利于架构师实现关注点分离，并将关注重心放在适配器与通信端口上。演练：六边形架构的通信边界案例：大型金融系统的客户管理第二天（上午）第四单元领域驱动设计的战术设计1、领域模型通过限界上下文，可以帮助我们分析系统的领域模型，包括系统的核心领域与子领域。确定系统的核心领域与子领域可以帮助架构师合理分配资源（包括时间资源与人力资源）。而对子领域的进一步识别，可以帮助架构师更好地识别可重用资源，包括可重用的功能模块，确定技术栈，决定构建还是购买的架构战略。3、四色建模法首先以满足管理和运营的需要为前提，寻找需要追溯的事件。根据这些需要追溯，寻找足迹以及相应的时标性对象。寻找时标对象周围的人事物。从中抽象角色，把一些信息用描述对象补足。案例分析：配送管理系统的四色建模2、实体（Entity）与值对象（Value Object）这两个概念都是领域对象的体现，二者的主要区别在于对“标识”的运用。本部分的内容深入展开对实体标识的讨论，揭示实体的本质特征，挖掘实体的关键行为。通过识别角色与职责对实现进行分析。本部分内容还将通过深入讲解值对象的特征帮助我们分辨值对象与实体，使得我们可以在领域驱动设计中有效地运用实体与值对象。本部分内容还包括持久化值对象，以及领域驱动设计与ORM之间的关系。3、领域服务 (Domain Service)通过讲解什么是领域服务，什么不是领域服务理清领域服务的概念，并讲解如何建模领域服务。讨论领域服务和面向接口设计思想。 4、聚合 (Aggregation)聚合是领域驱动设计最为重要的领域概念。本部分内容将深入探讨聚合的设计原则，并辨别在聚合设计中可能出现的坏味道，并提出针对性的解决方案。这些原则和方案包括：在一致性边界之内建模真正的不变量，设计小的聚合，通过唯一标识引用其他聚合，在边界外满足最终一致性。5、工厂(Factory)和资源库(Repository)工厂和资源库都是管理领域对象（实体、值对象和服务）生命周期的对象。工厂主要针对内存中对象从无到有的创建过程，与设计模式的工厂模式基本相似。资源库则分为面向集合的资源库与面向持久化的资源库。本部分内容将重点讲解与资源库直接相关的技术细节，包括如何选择资源库的方式，如何针对聚合持久化资源库，如何管理事务，以及分辨资源库与数据访问对象（DAO）之间的异同。7、应用层(Application Layer)设计作为为UI提供的应用服务，其目的在于管理和协调领域对象，并为领域对象提供横切关注点的内容。好的应用服务设计不应该承担任何与领域逻辑有关的职责。应用层是架构层面的外观与适配器模式的体现。它可以提高软件系统架构的可用性与简单性，也能够更好地与面向服务架构或RESTful架构风格结合。第二天（下午）第五单元系统重构1、软件业者的反思： 软件腐烂隐匿的腐烂：软件逐渐不再（仍）被使用随着剩余的应用程序的改变变得不能用。它已经被观察到不再被使用的软件有可能一年的半衰期；活动的腐烂：软件随着不断地被修改趋向于失去它的完整性。2、破窗效应与技术债务技术债务是不可避免的，然而对技术债务视而不见，则可以导致破窗效应。3、重构 何时重构 重构的误区 重构是持续进行的,不要先编写烂代码，再抽出重构 如何发现哪些地方需要重构 如何保证重构的正确 如何测试重构4、重构技术难题 如何发现重构点 知道重构的目标（结果） 如何去重构重构实践 如何保证重构的正确性-单元测试第三天第六单元优良API设计1、优良API的特征API的设计与普通接口的设计有相似之处，需要遵循相同的设计原则，但要求会更严格。因此，优良的API设计需要充分考虑API的可读性、可扩展性与可维护性以及可测试性。 2、API的演化与版本兼容性产品设计不可能一蹴而就，需要不停迭代和变化，从而产生版本变迁，API也将随之演化。设计时，需要考虑API的向后兼容，包括源代码兼容、二进制兼容与功能兼容。3、API设计的层次与粒度API设计与架构直接相关，需要考虑系统各模块之间的松散耦合，以及模块之间的通信方式。这些设计要素会直接决定API所处的层次以及设计粒度。4、REST风格的API领域驱动设计中的开放主机服务（OHS）多数是以REST方式暴露出来的服务。在软件领域中，服务成为越来越重要的重用单位，因而如何设计REST风格的AP