领域驱动设计与系统重构以及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） 这两个概念都是领域对象的体现，二者的主要区别在于对“标