对于从来没有接触过DDD的同学，建议可以先看下这篇文章，如果你听说过DDD，也可以通过下面这篇文章温习一遍DDD中基本的概念：爱吃牛油果的璐璐：算法架构师谈谈领域驱动设计DDD

接下来进入今天的主题：深入浅出聊聊DDD

Domain Drive Design 简称DDD。

DDD是从系统的分析到软件建模的一套方法论。下面给一个简单的公式：DDD=哲学+语文+技术，从这个公式可以看到技术放到最后，在DDD中技术不是最重要的，所谓语文就是利用文字将面向不同角色的人都能理解整个架构设计，不仅仅是技术人员，哲学放在最前面，是整个DDD的灵魂。DDD是一套完整而系统的设计方法、是一种设计思维、一种方法论，并不是 “系统架构”，一种架构设计原则、思维。

领域驱动设计用途

  • 善于处理高复杂业务的产品研发、可帮助我们提炼稳定的产品内核（领域模型中称为核心域）;
  • 通过建模可提高建模高内聚、降低模型间的耦合度，提高系统的可扩展性与稳定性；
  • 强调团队与领域专家的合作沟通，有助于建立一个沟通良好的团队组织；
  • 统一设计思想与设计规范，有助于提高团队成员的架构设计能力和面向对象设计能力；
  • 现有的微服务建构都是遵循领域驱动设计的架构原则；

经典分层架构与DDD分层架构

经典分层架构总结

三层应用架构：数据 - 应用 (业务逻辑层)- 展现，通常是以数据位为起点进行数据库分析设计。

  • 服务层过重，数据模型失血，没东西；
  • 面条式编程或者面向数据库编程，服务层围绕数据库作业完成业务逻辑，经常一条线撸到底；
  • 代码一整块一整块的过重，很难扩展复用；

数据库模型只是数据库映射，没有相关的行为支撑，行为都被上一层 Service 给完成等了，因此是失血的领域模型；

DDD分层架构总结

架构四层在 DDD 分层结构中将三层中业务逻辑拆解为应用层和领域层，核心业务逻辑表现下沉到领域层去实现，以业务领域模型为核心建模 (面向对象建模)，更能体现对现实世界的抽象，其优点如下：

  • 轻服务层 + 充血的领域模型；
  • 领域模型封装和实现各自应有的行为，可以认为是一个高内聚、低耦合的组件；
  • 由于模型集数据与行为于一身，是一种自解释的对象，代码复用性高，业务逻辑清晰明确；

用户界面层：主要职责是通过用户界面向用户显示数据信息，同时解释用户的命令，并把用户的请求发送到应用层。

应用层：通过调用基础设置和领域层完成数据资源操作及业务流程编排，相当于 BS 层；

领域层：将业务逻辑高度内聚到领域层，所以领域层是整个系统的核心，它只与实际业务相关，不关心任何技术细节，尽可能做到与持久化无关；

基础设施层：包含了任何类型的框架、数据库访问代码或者公共的方法等，纯技术的一层；

DDD思维导图

领域模型不应该包含任何技术实现因素，模型中的对象真实的表达了领域概念，却不受技术实现的约束，领域模型本身和技术无关，领域驱动从设计上划分为战略设计和战术设计。

战略设计强调业务战略上的重点，如何按重要性分配工作，以及如何进行最佳，遵循量大原则。

子域划分分为：核心子域：领域中最有价值和最核心的部分，产品成败的关键，核心竞争力，在 DDD 开发中，主要关注核心域，给予最高优先级；支撑子域：项目中对核心子域起着支撑作用的相关功能，专注于业务的某个反面；通用子域：与项目意图无关的内聚子领域，解决一些通用问题，任何专有的业务都不应该放在通用子域；

战略建模关注点在于系统物理划分，根据对领域的分割结果及公司或部门的组织结构决策如何划分子系统，比如分出几个，系统间如何交互，该层面往往暂不会涉及过多技术细节。 限界上下文 (Bounded Context): 通俗讲指系统中模块，微服务架构中的子服务、单体中 “包” 或名称空间 ，对系统的一个物理划分，限定了领域模型的边界，在更深层次介绍深挖，这东西得分成两个词：限界、上下文，可以理解成系统设计之初，你需要画一个圈设置一个范围，保证领域模型限制在这个圈内不可串场，这个‘圈’即为限界上下文。**通用语言：**用于统一领域专家、产品、研发、测试大家在使用的语言，避免出现需求理解不一致，设计与需求不一致，沟通不顺畅等问题，简单来说大家在一起聊某个东西的时候都能明白彼此所致的是什么，场景不同，同一个词就会有着不同含义。上下文映射图：用图的方式，表达出限界上下文之间关联，如合作关系、防腐层、大泥球等。

战术设计主要包括：代表领域中的概念，如实体、值对象、领域服务、模块等；用于管理对象的生命周期。如聚合、工厂、仓库等；用于集成或跟踪，如领域事件等。