一句话理解DDD用业务语言统一代码和需求让复杂系统按业务边界清晰拆分。领域驱动设计DDD近年来备受关注尤其在企业软件和SaaS领域。但很多开发者读完《领域驱动设计》后依然感到困惑——概念太抽象落地太难。本文将通过一个虚拟公司的实际案例带你从零开始理解DDD掌握战略设计与战术设计的核心要点最终实现DDD在项目中的落地。一、为什么需要领域模型传统的MVC模式在简单业务场景下运作良好但随着业务复杂度增加问题逐渐暴露缺乏业务语言MVC仅反映软件层面架构无法直接与业务对话数据与行为分离数据库存储数据服务层实现行为容易导致需求理解偏差边界模糊缺乏明确的边界划分规范大规模团队协作容易职责不清领域模型的价值在于统一语言让产品、设计、开发用同一套术语沟通业务与技术解耦领域模型和数据模型分离聚焦业务本质知识沉淀模型与软件实现关联业务知识得以传递和积累二、DDD核心概念速览2.1 战略设计从全局视角规划战略设计解决怎么拆的问题主要包括概念说明示例领域组织要做的全部事情知识付费领域子域领域中独立的业务板块订阅域、专栏域、金融域核心域决定核心竞争力的子域订阅域付费订阅是核心业务通用域被多个子域使用的通用功能权限域、登录域支撑域支撑其他业务的企业特性功能评论域、专栏域限界上下文业务边界的划分对应微服务专栏订阅上下文2.2 战术设计具体实现层面战术设计解决怎么实现的问题主要包括实体有唯一标识和生命周期的业务对象如订阅、专栏值对象无标识、不可变的属性组合如地址、金额聚合一组有相同生命周期的实体和值对象的集合聚合根聚合对外的唯一入口领域服务不属于任何实体的领域行为资源库封装数据访问逻辑领域事件领域内发生的重要事情三、实战案例RabbitTech知识付费平台假设我们是RabbitTech公司的CTO需要设计一个知识付费产品RabbitAdvisors。3.1 业务场景分析核心业务流程作者开设专栏用户浏览专栏用户付费订阅用户阅读内容公司与作者分成3.2 领域划分知识付费领域├── 订阅域核心域- 订阅、订单├── 专栏域支撑域- 专栏、文章├── 金融域支撑域- 分成、结算├── 用户域通用域- 用户、权限└── 评论域支撑域- 评论、点赞3.3 限界上下文划分┌─────────────────────────────────────┐│ 专栏订阅上下文微服务1 ││ ┌─────────┐ ┌─────────┐ ││ │ 订阅域 │ ←─── │ 订单域 │ ││ └─────────┘ └─────────┘ │└─────────────────────────────────────┘┌─────────────────────────────────────┐│ 专栏管理上下文微服务2 ││ ┌─────────┐ ┌─────────┐ ││ │ 专栏域 │ ←─── │ 文章域 │ ││ └─────────┘ └─────────┘ │└─────────────────────────────────────┘3.4 聚合设计示例以订阅聚合为例订阅聚合│├── 订阅聚合根│ ├── id: SubscriptionId│ ├── userId: UserId│ ├── columnId: ColumnId│ ├── status: SubscriptionStatus│ └── subscribedAt: DateTime│├── 订阅项实体│ └── 文章阅读记录│└── 值对象├── 订阅时长└── 付款金额四、统一语言团队协作的基石统一语言是DDD的核心实践它要求团队在所有沟通中使用一致的术语。4.1 定义统一语言以用户订阅专栏为例术语定义用户(User)在RabbitAdvisors注册过的人专栏(Column)作者创建的内容集合订阅(Subscription)用户付费购买专栏的记录订单(Order)用户支付行为的记录4.2 在代码中应用统一语言// 统一语言体现在类名、方法名、变量名中public class Subscription {private SubscriptionId id;private UserId userId;private ColumnId columnId;private SubscriptionStatus status;public void activate() {if (this.status ! SubscriptionStatus.PENDING) {throw new IllegalStateException(只有待激活的订阅可以激活);}this.status SubscriptionStatus.ACTIVE;}}五、DDD落地的关键实践5.1 实体模型选择实体有四种常见形态模型类型特点适用场景失血模型仅有数据定义和getter/setter简单CRUD贫血模型包含部分业务逻辑DDD推荐充血模型包含所有业务逻辑复杂业务核心胀血模型包含非业务逻辑不推荐推荐实践采用贫血模型实体和领域服务共同构成领域模型。5.2 聚合设计原则一致性边界聚合内的对象必须保持一致性通过聚合根访问外部只能通过聚合根访问聚合内对象小聚合优先聚合越小越好降低并发冲突最终一致性聚合之间通过领域事件保持最终一致5.3 限界上下文与微服务限界上下文是微服务拆分的天然边界一个限界上下文 ≈ 一个微服务划分原则- 支持完整的业务流程- 团队自主性- 独立部署能力六、DDD不是银弹DDD也有其适用边界适合DDD的场景业务复杂、规则多变团队规模较大领域专家参与度高期演进的产品不适合DDD的场景简单CRUD系统快速原型验证小团队、短期项目技术驱动而非业务驱动七、总结DDD的本质不是技术而是用业务视角思考和设计战略设计告诉你系统该怎么拆战术设计告诉你代码该怎么写统一语言让团队说同一种话领域模型是业务知识的沉淀记住DDD是方法论不是框架。它提供的是一种思考方式帮助你更好地理解和建模复杂业务领域。本文代码示例可在以下仓库找到后端微服务github.com/eyebluecn/smart-classroom-misc前端项目github.com/eyebluecn/smart-classroom-front在线演示classroom.eyeblue.cn
