DDD领域驱动设计.pdf

DDD领域驱动设计 DDD领域驱动设计 1. 领域驱动设计 1.1 领域驱动概述 领域驱动设计(Domain Driven Design) 是⼀种从系统分析到 件建模的⼀套⽅法论。以领域为核⼼驱动⼒的设计体系。 为什么使⽤领域驱动设计 1.⾯向对象设计，数据⾏为绑定，告别贫⾎模型。 2.优先考虑领域模型，⽽不是切割数据和⾏为。 3.准确传达业务规则。 4.代码即设计。 5.它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应⽤边界，可以很容易地实现业务和技术统⼀的架构演进。 领域驱动设计，⼜称 件核⼼复杂性应对之道。是⼀套基于对象思维的业务建模设计思想，相对于 CRUD 系统有更⾼的灵活性，是业务 ⼈员处理复杂问题的有效⼿段。 1.2 领域驱动优点 DDD最⼤的好处是 ：接触到需求第⼀步就是考虑领域模型，⽽不是将其切割成数据和⾏为，然后数据⽤数据库实现，⾏为使⽤服务实现，最 后造成需求的⾸肢分离。DDD让你⾸先考虑的是业务语⾔，⽽不是数据。DDD强调业务抽象和⾯向对象编程，⽽不是过程式业务逻辑实 现。重点不同导致编程世界观不同。 1.⾯向对象 封装 ：Account的相关操作都封装在Account Entity上，提⾼了内聚性和可重⽤性。 多态 ：采⽤策略模式的OverdraftPolicy （多态的典型应⽤）提⾼了代码的可扩展性。 2.业务语义显性化 通⽤语⾔ ： “⼀个团队，⼀种语⾔”，将模型作为语⾔的⽀柱。确保团队在内部的所有交流中，代码中，画图，写东西，特别是讲话的时候 都要使⽤这种语⾔。例如账号，转账，透⽀策略，这些都是⾮常重要的领域概念，如果这些命名都和我们 ⽇常讨论以及PRD中的描述保持⼀ 致，将会极⼤提升代码的可读性，减少认知成本。说到这，稍微吐槽⼀下我们有些⼯程师的英语⽔平，有些神翻译让⼀些核⼼领域概念变得 ⾯⽬全⾮。 显性化 ：就是将隐式的业务逻辑从⼀推if-else⾥⾯抽取出来，⽤通⽤语⾔去命名、去写代码、去扩展，让其变成显⽰概念，⽐如透⽀策 略这个重要的业务概念，按照事务脚本的写法，其含义完全淹没在代码逻辑中没有突显出来，看代码的⼈ ⾃然也是⼀脸懵逼，⽽领域模型 ⾥⾯将其⽤策略模式抽象出来，不仅提⾼了代码的可读性，可扩展性也好了很多。 1.3 DDD解决复杂度的⽅式 ⾸先, 典型的DDD实现了业务复杂度和技术复杂度的隔离，通过分层架构隔离了关注点，举个例⼦，在传统的DDD四层架构中，DDD划分 出了领域层、仓储层、基础设施层、接⼝层 ； 在领域层中，存放业务逻辑的关注点，即所谓的领域⾏为 ；在应⽤层中，DDD暴露出了 业务⽤例级别 （Use Case）的服务接⼝，粘合业 务逻辑与技术实现 ；在基础设施层中，DDD集中放置了⽀撑业务逻辑的技术实现，如 ：MQ消息发送、对缓存的操作等 ；在仓储层中，DDD 放置了和领域状态相关的逻辑，打通了领域状态持久化与存储设施之间的联系。 除了划分不同分层外，DDD还提出了⼀个建设性的概念: “限界上下⽂ （Bounded Context）”，通过限界上下⽂对业务流程分⽽治之， 切分为不同的⼦系统，在每个⼦系统中利⽤DDD的分层架构/六边形架构等思想分别进⾏逻辑分层。通过这样的分治之后，DDD帮我们将业 务复杂度隔离到了每个细分的领域内部，⽽且DDD本⾝的分治思想，也帮助我们隔离了业务需求和技术需求的关注点。 这是⼀个典型的领域驱动设计分层架构，蓝⾊区域的内容与业务逻辑有关，⽽灰⾊区域的内容则与技术实现有关。这⼆者泾渭分明，最后汇 合在应⽤层。 应⽤层确定了业务逻辑与技术实现的边界，通过直接依赖或者依赖注⼊ （DI，Dependency Inj ection）的⽅式将⼆者结合起来。充分体现 了DDD能够隔离技术复杂度与业务复杂度的特点。 2. 领域核⼼知识体系 2.1 领域知识概念 DDD的核⼼知识体系主要包括领域、⼦域、核⼼域、⽀撑域、通⽤域、限界上下⽂、实体、值对象、聚合、聚合根等概念。 2.2 领域战略战术设计 DDD有战略设计和战术设计之分。战略设计主要从⾼层俯视我们的 件系统，帮助我们精准地划分领域以及处理各个领域之间的关系 ；⽽ 战术设计则从技术实现的层⾯教会我们如何具体地实施DDD。 战略建模-Strategic Modeling 限界上下⽂ （Bounded Context） 上下⽂映射图 （Context Mapping） 战术建模-Tactical Modeling： 聚合-Aggregate