领域驱动设计（Domain-Driven Design, DDD）-海口c网

博主介绍：✌全网粉丝5W+，全栈开发工程师，从事多年软件开发，在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战，博主也曾写过优秀论文，查重率极低，在这方面有丰富的经验✌

博主作品：《Java项目案例》主要基于SpringBoot+MyBatis/MyBatis-plus+MySQL+Vue等前后端分离项目，可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程，企业实战开发。《微服务实战》专栏是本人的实战经验总结，《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味，更多惊喜等着你哦

🍅uniapp微信小程序🍅面试题软考题免费使用，还可以使用微信支付，扫码加群。由于维护成本问题得不到解决，可能将停止线上维护。

🍅文末获取联系🍅精彩专栏推荐订阅👇🏻👇🏻 不然下次找不到哟

Java项目案例《100套》
https://blog.csdn.net/qq_57756904/category_12173599.html
uniapp小程序《100套》

https://blog.csdn.net/qq_57756904/category_12173599.html

有需求代码永远写不完，而方法才是破解之道，抖音有实战视频课程，某马某千等培训都是2万左右，甚至广东有本科院校单单一年就得3万4年就12万学费，而且还没有包括吃饭的钱。所以很划算了。另外博客左侧有源码阅读专栏，对于求职有很大帮助，当然对于工作也是有指导意义等。在大城市求职，你面试来回一趟多多少少都在12块左右，而且一般不会一次性就通过，还得面试几家。而如果你对源码以及微服务等有深度认识，这无疑给你的面试添砖加瓦更上一层楼。

最后再送一句：最好是学会了，而不是学废了！！

领域驱动设计（Domain-Driven Design, DDD）。

DDD 不仅仅是一套技术或模式，它更是一种思维方式和一套设计原则，旨在应对复杂软件系统（尤其是业务系统）开发中的核心挑战：将业务领域的复杂性与软件实现紧密、有效地结合起来。

它的核心思想是：软件系统的结构、语言和行为应该深刻反映并专注于其核心业务领域。

DDD 诞生的背景和要解决的问题

沟通鸿沟： 业务专家（领域专家）和开发人员使用不同的语言和思维模式，导致需求理解偏差、设计偏离业务本质。
模型与实现脱节： 设计文档中的“理想模型”与实际代码结构差异巨大，导致维护困难，代码难以反映业务变化。
软件复杂度失控： 当业务逻辑分散在数据库、UI、服务层等各处时，系统变得难以理解和修改。
无法有效应对变化： 业务需求变化时，修改代码牵一发而动全身，成本高昂且风险大。

DDD 的核心概念与组成部分

DDD 可以分为战略设计和战术设计两大支柱：

一、战略设计：关注高层次的组织结构和边界划分

统一语言（Ubiquitous Language）：
- 核心理念！ 项目团队（包括领域专家、开发、测试、产品等）共同创建一套精确的、无歧义的、基于业务领域的词汇表。
- 这套语言贯穿于需求讨论、设计文档、代码实现（类名、方法名、变量名）、测试用例等所有环节。
- 目标： 消除沟通障碍，确保所有人对业务概念的理解完全一致，代码就是领域模型最直接的表达。
限界上下文（Bounded Context）：
- 关键战略模式！ 大型复杂领域会被分解成若干个较小的、内聚的、语义清晰的子领域（Subdomain）。每个子领域对应一个限界上下文。
- BC 定义了：
  - 一个明确的边界，在这个边界内，特定的统一语言具有特定的、一致的含义。
  - 一个领域模型的有效范围和生命周期。
- 类比： 就像生物体的细胞，每个细胞（BC）有自己的职责和内部环境（模型），并通过细胞膜（边界）与其他细胞进行清晰、受控的交互。
- 重要性： 防止模型概念在不同上下文中的含义混淆（例如，“客户”在销售上下文和财务上下文中含义可能不同），是微服务拆分的重要依据。
上下文映射图（Context Mapping）：
- 描述不同的限界上下文之间如何交互和集成的图。
- 定义了交互模式（如：合作关系、客户方-供应方开发、遵奉者、防腐层、开放主机服务、发布语言、分离方式等）。
- 目标： 清晰展示系统整体结构，管理跨边界的依赖和集成复杂性。
核心域、支撑域、通用域（Core Domain, Supporting Subdomain, Generic Subdomain）：
- 核心域： 是整个系统的核心竞争力所在，是业务差异化的关键，需要投入最多的精力和最优秀的人才进行深度建模和创新。
- 支撑域： 为核心域提供必要的支持功能，对业务很重要但不是核心竞争力（如：报表、特定工作流）。可以投入较少资源或考虑购买/外包方案。
- 通用域： 非常通用、行业标准化的功能（如：身份认证、日志、通知）。通常建议使用现成的、成熟的解决方案（库、框架、SaaS），避免重复造轮子。
- 目标： 帮助团队识别战略重点，合理分配资源。

二、战术设计：关注如何在限界上下文内部构建领域模型和实现细节

实体（Entity）：
- 具有唯一标识符（ID）和生命周期（会经历创建、修改、删除）的对象。
- 标识符是其身份的核心，即使属性发生变化，只要ID不变，就还是同一个实体。
- 例子： Customer (有唯一的 CustomerID), Order (有唯一的 OrderID)。
值对象（Value Object）：
- 描述事物的特征（属性），但没有概念上的标识符或生命周期。
- 其相等性基于所有属性的值是否相等。
- 通常是不可变（Immutable） 的。修改意味着创建一个新的值对象实例。
- 例子： Money (包含 Amount 和 Currency), Address, Color。
聚合（Aggregate）与聚合根（Aggregate Root）：
- 关键模式！ 将一组强相关的实体和值对象组合成一个一致性边界。
- 聚合根（Aggregate Root）： 聚合的入口点。外部只能通过聚合根来访问或修改聚合内部的对象。
- 聚合根负责维护聚合内部的业务规则和不变量（在任何操作后都必须为真的条件）。
- 聚合作为一个整体被加载和持久化（通常对应数据库的一个事务边界）。
- 目标： 定义清晰的业务一致性边界，简化模型关系，控制对象访问，是事务设计的基础。
- 例子： Order (聚合根) 包含多个 OrderItem (实体) 和一个 ShippingAddress (值对象)。修改 OrderItem 的数量必须通过 Order 进行，Order 会检查总金额等不变量。
领域服务（Domain Service）：
- 当某个重要的业务操作或规则无法自然地归属于某个实体或值对象时（通常是跨多个聚合的操作，或需要访问基础设施但本质是业务逻辑的操作），将其封装在领域服务中。
- 服务应该是无状态的。
- 例子： FundsTransferService (处理两个银行账户之间的转账逻辑，涉及两个 Account 聚合)。
领域事件（Domain Event）：
- 表示在领域内发生的、对业务有重要意义的事实（Fact）。
- 是过去时态（如：OrderPlaced, PaymentReceived, InventoryAdjusted)。
- 用于：
  - 解耦： 一个聚合执行操作后发布事件，其他聚合或限界上下文监听并作出反应。
  - 通知： 通知系统其他部分（如：发送邮件、更新视图模型）。
  - 审计/溯源： 记录系统状态变化的历史。
  - 实现最终一致性： 在分布式系统中协调跨聚合/上下文的数据变更。
仓储（Repository）：
- 提供对聚合根进行持久化和检索的接口（抽象）。
- 客户端（如应用服务）通过仓储接口（如 IOrderRepository）获取聚合根（如 Order），操作聚合根，然后通过仓储保存更改。
- 目标： 封装持久化细节（ORM, 数据库等），让领域层专注于业务逻辑，不依赖基础设施。
工厂（Factory）：
- 封装复杂对象或聚合的创建逻辑。当对象的构造过程本身很复杂（涉及多个步骤、规则验证）时使用。
- 可以是独立的工厂类，也可以是聚合根上的工厂方法。

分层架构（常用）

DDD 项目通常采用分层架构来分离关注点：

用户界面层 / 表现层： 处理用户交互、展示数据、接收命令。可以是 Web API, MVC Controller, GUI 等。
应用层：
- 协调领域对象和基础设施（如仓储）来完成一个特定的应用任务（用例/用户故事）。
- 很薄，主要包含流程控制（调用领域服务、聚合根方法、发送命令、发布事件等）。
- 不包含核心业务逻辑。
领域层：
- 核心！ 包含业务概念、规则、状态（实体、值对象、聚合根、领域服务、领域事件）。
- 是软件的核心价值所在，应该尽可能保持纯净（Persistence Ignorant），不依赖基础设施（数据库、网络、框架等）。
基础设施层：
- 为上层提供技术实现细节：数据库访问（实现仓储接口）、消息队列、文件系统操作、邮件发送、框架配置等。
- 领域层和应用层通过接口（抽象）依赖于基础设施层提供的具体实现。