领域驱动设计为什么存在：从统一语言到知识提炼

DDD 解决的不是“代码怎么分层”这么窄的问题，而是复杂业务知识如何进入软件系统的问题。很多失败的系统并不是技术不够先进，而是业务语言、模型边界和代码实现长期脱节。

问题背景

当业务复杂度上升时，需求文档、会议口头表达、数据库字段和代码类名经常各说各话。开发者以为自己理解了需求，业务方以为系统表达了规则，最后问题暴露在验收、运营和线上异常里。

核心概念

统一语言是业务方和开发方共同使用的词汇；领域模型是这些词汇背后的规则结构；限界上下文定义模型生效的边界。DDD 的重点是让这些概念可以被反复验证，而不是只停留在图上。

flowchart LR
    A["业务知识"] --> B["统一语言"]
    B --> C["领域模型"]
    C --> D["软件实现"]
    D --> E["反馈与修正"]
    E --> A

实际工程场景

在订单、计费、库存、审批这类业务里，一个词往往在不同场景下含义不同。例如“订单”在销售上下文里关注成交，在履约上下文里关注发货，在财务上下文里关注结算。把这些差异压进一个通用 Order 类，会让模型越来越混乱。

常见误区

• 把 DDD 等同于战术模式清单，只讨论聚合、仓储、值对象。
• 在没有业务共识时先拆服务，导致服务边界只是数据库表边界。
• 把统一语言写在文档里，却没有落实到代码命名、接口和测试用例。

最佳实践

• 从业务事件、规则冲突和术语歧义开始建模。
• 让模型边界跟业务语义一致，而不是跟技术层级一致。
• 用测试和示例固化语言，例如“订单已支付但未履约”。
• 定期回看模型是否仍然表达当前业务，而不是把初版模型当成真理。