DDD领域驱动设计（领域，子域，界限上下文）

       

目录

1 MVC与DDD

2概念

3 使用场景

---

领域模型类型（失血，贫血，充血，胀血）_贫血模型 充血模型 胀血模型-优快云博客

界限上下文识别-优快云博客

DDD（domain driven design，领域驱动设计），2003提出，是为了解决快速变化，复杂系统设计问题。

DDD是一种软件设计思想和方法论，以领域为核心构建软件设计体系，将业务模型抽象成领域模型进行拆解和封装。
DDD不是一种架构，而是一种架构方法论，是一种拆解业务、划分业务、确定业务边界的方法，是一种领域设计思想。
DDD（领域驱动设计）实际上是一套软件架构设计的方法论，我们可以在此之上更好的理解业务。并且我们可以根据这套方法论进行架构风格填充，包括微服务架构，面向服务架构，REST风格架构以及六边形架构等等。
 

1 MVC与DDD

先来看看传统三层架构和DDD四次架构的区别

1在架构设计上，在DDD分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层
其中Application划分为很薄的一层服务，非核心的逻辑放到此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更为精确的业务规则集合，通过领域对象去阐述说明。

2在建模方式上，DDD分层的建模思维方式有别于传统三层。传统三层通常是以数据库为起点进行数据库分析设计，而DDD则需要以业务领域模型为核心建模（即面向对象建模方式），更能体现对现实世界的抽象。
故在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有的业务领域模型的抽象表达。

3在职责划分上，基础设施层涵盖了2方面内容
持久化功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现
通用技术支持，一些公共通用技术支持也放到基础设施层去实现。

分层	描述
表现层	User Interface 用户界面层，或者表现层，负责向用户显示解释用户命令
应用层	Application Layer 定义软件要完成的任务，并且指挥协调领域对象进行不同的操作。该层不包含业务领域知识。
领域层	Domain Layer 或称为模型层，系统的核心，负责表达业务概念，业务状态信息以及业务规则。即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面入手
基础设施层	Infrastructure Layer 主要有2方面内容，一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；一是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现；

2概念

领域与具体开发技术无关。就是软件系统要解决的实际问题相关的所有东西的集合。比如电子商城卖书，那么如何进货，如何决定优惠规则，如何安排物流，如何管理客户级别，如何分析销售数据等等，这直接与业务相关的所有东西都归属于“领域”。DDD就是说你得先把领域中涉及到的数据、流程、商业规则等都弄明白了，然后以面向对象的观点为其建立一个模型（领域模型），再选用合适的软件技术去实现这个模型。

       问题空间是核心域和其他子域的组合。解决方案空间包括一个或者多个限界上下文，即一组特定的软件模型。这是因为限界上下文本身就是一个特定的解决方案。
       领域可再划分为多个子领域，即子域。每个子域对应一个更小的问题域或业务范围。比如酒店行业，一开始的酒店核心系统是单体架构，后来业务发展，开始转型中台，引入微服务。微服务架构就需划分业务领域边界，建立领域模型，并实现微服务落地。可根据业务关联度及流程边界将酒店领域细分为：预订，入住，退房，客房服务，点餐等领域事件。

        网上预订，入住，退房。是酒店领域一定要有的功能，这就是核心子域。
        客房服务，点餐等不影响主要功能的就是支撑子领域。
在预订这个限界上下文内可以建立预订的领域模型，领域模型最后映射到系统就是预订微服务。
不同行业的业务模型可能不同，但领域建模过程类似，核心思想都是将问题域逐步分解，降低业务理解和系统实现的复杂度。

领域可细分为不同子域，子域可根据自身重要性和功能属性划分为三类子域：

1 核心域
决定产品和公司核心竞争力的子域，是业务成功的主要因素和公司的核心竞争力。

2 通用域
没有太多个性化需求，同时被多个子域使用的通用功能子域。比如认证、权限等，无企业特点限制，无需太多定制化。

3 支撑域
既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又是必需的支撑域。支撑域具有企业特性，但不具通用性，例如数据代码类的数据字典等系统。

领域的核心思想是将问题域逐级细分，降低业务理解和系统实现的复杂度。
通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，映射成系统就是微服务。

4 界限上下文

        界限上下文就是边界的意思。通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧，分别以不同的视角、不同的角色协作来运用对应的设计原则，会是一个可行的识别限界上下文的过程方法。

        两个限界上下文之间的关系是有方向的，领域驱动设计使用两个专门的术语来表述它们：“上游（Upstream）”和“下游（Downstream）”，在上下文映射图中，以 U 代表上游，D 代表下游，理解它们之间的关系，正如理解该术语隐喻的河流，自然是上游产生的变化会影响到下游，反之则不然。故而从上游到下游的关系方向，代表了影响产生的作用力，影响作用力的方向与程序员惯常理解的依赖方向恰恰相反，上游影响了下游，意味着下游依赖于上游。

3 使用场景

为什么DDD常年热度不减，但在我们实际的系统开发过程中，却很少有完全落地的项目呢？或者说MVC架构风格的系统很常见，但DDD架构风格的系统却很少见到。这得回归到DDD本身：它是解决复杂业务的一种软件开发方法论。

如果将普通的CRUD业务系统也按照这套模式实现，反而会增加系统的复杂度。总体来说，DDD模式适用于以下几种场景：

1. 支持处理复杂业务逻辑场景：当应用程序需要处理复杂的业务逻辑时，DDD可以将业务逻辑封装在领域模型中，从而更好地反映业务需求和业务流程，降低了系统架构的复杂度；

2. 高度可维护和可扩展性场景：DDD将应用程序拆分成多个子域，每个子域都有自己的领域模型，这样可以更好地管理业务复杂性；

3. 需要快速迭代和交付的场景：每个子域都可以独立开发、部署和扩展，这样可以使得团队可以快速迭代和交付应用程序；