摘要：在 ERP（企业资源计划）项目开发中，我们常面临一个核心挑战：如何将复杂多变的业务规则转化为可维护、可扩展的代码？传统的 "数据库优先" 或 "贫血模型" 开发模式，往往导致业务逻辑分散在服务层、控制器甚至 UI 层，当业务规模扩大时，代码会变得臃肿且难以迭代
在 ERP（企业资源计划）项目开发中，我们常面临一个核心挑战：如何将复杂多变的业务规则转化为可维护、可扩展的代码？传统的 "数据库优先" 或 "贫血模型" 开发模式，往往导致业务逻辑分散在服务层、控制器甚至 UI 层，当业务规模扩大时，代码会变得臃肿且难以迭代。而领域驱动设计（DDD）通过聚焦业务领域本身，将代码与业务语言对齐，为解决这一问题提供了成熟的方法论。
我在多个大型 ERP 项目中实践过 DDD，深刻体会到它在复杂业务场景中的价值。本文将结合 C# 语言特性，从设计思想到具体实现，聊聊 DDD 在 ERP 项目中的应用。
业务规则复杂：从采购审批流程到库存预警策略，从成本核算到财务对账，每个模块都有大量行业特有的规则；
模块耦合深：一个业务动作（如 "销售出库"）可能涉及销售、库存、财务、物流等多个模块；
变更频繁：企业会因政策调整、业务扩张、管理升级等原因频繁修改流程，代码需具备快速响应能力；
数据一致性要求高：例如 "库存数量" 必须与 "订单明细"、"出入库单" 严格一致，不允许出现业务漏洞。
传统开发模式下，这些特点往往导致：
业务逻辑与技术实现混杂（如在 OrderService中同时写校验规则和数据库操作）；跨模块修改时牵一发而动全身（改库存逻辑可能影响采购、销售两个模块）；
新人接手时需花大量时间理解 "代码背后的业务"（因为代码没有用业务语言表达）。
而 DDD 的核心思想 ——"围绕业务领域建模，用代码映射业务语言"，恰好能解决这些问题：
通过限界上下文划分模块边界，降低耦合；
用聚合根、实体、值对象封装业务规则，确保数据一致性；
用领域事件解耦跨模块协作；
用领域服务封装复杂业务流程，避免逻辑分散。
C# 作为强类型面向对象语言，其特性（如record值对象、接口抽象、泛型约束）能完美支撑 DDD 的实现。1. 限界上下文：划分模块的 "业务边界"限界上下文（Bounded Context）是 DDD 的核心概念，它定义了一个 "业务领域的边界"，边界内的术语、规则、模型是统一的。在 ERP 中，我们可根据核心业务流程划分限界上下文：
限界上下文
核心业务
核心实体
采购管理 采购订单创建、供应商管理、采购入库 采购订单（PurchaseOrder）、供应商（Supplier） 销售管理 销售订单创建、客户管理、销售出库 销售订单（SalesOrder）、客户（Customer） 库存管理 库存盘点、出入库、库存预警 仓库（Warehouse）、库存记录（InventoryRecord） 财务管理 应收应付、成本核算 账单（Bill）、账户（Account）C# 实现技巧：通过命名空间（Namespace）体现限界上下文，例如：
1 2 3 4 5 // 销售管理上下文namespaceMysoft.Sales.Domain// 采购管理上下文namespaceMysoft.Purchasing.Domain跨上下文通信应避免直接引用，而是通过领域事件或上下文映射（如防腐层）实现。例如 "采购入库" 完成后，库存上下文需要同步更新库存，此时采购上下文发布PurchaseReceiptCreated事件，库存上下文订阅事件并处理。2. 领域模型：用代码表达业务规则领域模型是 DDD 的 "灵魂"，它由聚合根（Aggregate Root）、实体（Entity）、值对象（Value Object）组成，核心是封装业务规则（ invariants）。
（1）聚合根：确保业务一致性的 "管理者"聚合根是一组相关实体和值对象的集合，它负责维护整个聚合的业务规则，外部只能通过聚合根访问内部成员。在 ERP 中，"订单" 是典型的聚合根：
设计要点：
实体（Entity）是具有唯一标识的对象，其生命周期中属性可能变化，但标识不变。例如采购订单明细（PurchaseOrderItem（3）值对象：无唯一标识的 "不可变对象"值对象（Value Object）用于描述事物的属性，无唯一标识，且属性不可变（修改时需创建新对象）。ERP 中常见的 "金额"、"地址"、"商品信息" 等都适合作为值对象：
当业务逻辑涉及多个聚合根时，应使用领域服务（Domain Service）封装。例如 "库存不足时自动创建采购建议"，需要查询库存聚合和供应商聚合：
领域事件（Domain Event）用于记录领域中发生的重要事件，并通知其他模块处理。例如 "销售订单创建后，需要扣减库存"：
C# 实现：可借助 MediatR 库（.NET 生态常用的事件中介库）实现事件的发布与订阅，简化代码：
// 发布事件（在聚合根或领域服务中）await _mediator.Publish(new SalesOrderCreated(order));// 订阅事件（Handler自动被MediatR发现）
public class SalesOrderCreatedHandler : INotificationHandler5. 仓储：隔离数据访问细节
仓储（Repository）负责聚合根的持久化，屏蔽数据库操作细节，使领域层专注于业务。在 C# 中，通常通过接口定义仓储，在基础设施层用 EF Core 实现：
应用层（Application Layer）位于领域层之上，负责协调领域对象完成用户用例，不包含业务规则（业务规则在领域层）。例如 "创建采购订单" 的用例：
设计要点：应用层是 "协调者"，负责：
接收用户输入（DTO）；
调用领域层获取数据、执行业务逻辑；
处理事务（通过 IUnitOfWork）；返回结果（DTO）。
在 ERP 项目中落地 DDD，难免遇到一些挑战，结合 C# 生态可这样解决：
性能问题：聚合根过大时，查询可能加载过多数据。解决方案：用 "查询模型" 优化 —— 通过 EF Core 的Select投影查询，直接返回 DTO（绕过领域模型），仅在写操作时使用完整聚合。
与遗留系统集成：ERP 常需与旧系统（如财务软件）对接。解决方案：在限界上下文边缘添加 "防腐层"（Anti-Corruption Layer），将旧系统的数据格式转换为领域模型可识别的格式，避免领域层被污染。
团队认知成本：DDD 概念较多，团队上手慢。解决方案：先从核心模块（如订单管理）入手，通过代码示例（如本文的聚合根实现）建立共识；结合事件风暴（Event Storming）工作坊，让业务人员和开发人员共同梳理领域模型。
事务一致性：跨聚合操作需保证事务。解决方案：通过 "Saga 模式" 实现分布式事务 —— 将跨聚合操作拆分为多个本地事务，用领域事件串联，失败时执行补偿操作（如PurchaseOrderFailed事件触发库存回滚）。
DDD 并非银弹，但在 ERP 这类复杂业务系统中，它能帮助我们构建 "业务驱动" 的代码 —— 让代码像业务文档一样易读，让业务规则在领域模型中得到严格封装，让模块边界通过限界上下文清晰划分。
C# 的面向对象特性（封装、继承、多态）、record值对象、泛型、依赖注入等，为 DDD 的实现提供了天然支持。结合 EF Core（数据持久化）、MediatR（事件处理）、AutoMapper（DTO 转换）等库，我们能快速搭建一套成熟的 DDD 开发框架。最后想强调：DDD 的核心是 "理解业务"，代码只是业务的映射。在 ERP 项目中，与其纠结 "聚合根是否设计正确"，不如多花时间与业务人员沟通，让领域模型真正反映企业的业务流程 —— 这才是 DDD 的价值所在。
来源：opendotnet
