领域驱动设计（DDD）可否采用用例驱动？从用例启动开发是否合规？

这确实是DDD实践里非常常见的困惑——理论上我们常说DDD要“以领域为驱动”，得先吃透问题域、用通用语言构建领域模型，再基于模型开发应用层的用例；但实际项目中，很多团队却是从用例入手推进开发，看起来好像和理论相悖，但其实这两种路径不仅不矛盾，反而能形成互补的迭代闭环。

先澄清一个核心误区：DDD的本质是围绕业务问题和通用语言构建解决方案，而非刻板遵循“先模型后用例”的固定流程。理论里的“先构建领域模型”，是一种理想的自上而下推导，但真实项目中，我们几乎不可能一开始就对复杂的问题域有完整、精准的理解——尤其是面对陌生业务时，直接抽象模型很容易陷入“空想式设计”。

那为什么从用例切入是合理的？有几个关键原因：

• 用例是业务需求的具象锚点：用例直接对应真实的用户/角色交互场景（比如“用户创建订单”“管理员审核退款”），能让团队快速聚焦核心业务动作，避免一开始就陷入抽象概念的迷雾。从这些具体场景入手，我们能更快摸到业务的核心痛点和规则。
• 用例是通用语言的迭代载体：写用例的过程中，我们会自然使用业务团队的术语（比如“订单锁定”“库存扣减”），这些术语就是通用语言的雏形。把用例里的业务逻辑反向提炼到领域模型，再用模型验证用例是否符合领域规则，这个双向迭代的过程，恰恰是DDD强调的“融合业务与技术语言”的核心。
• 适配敏捷开发的节奏：很多团队会从小规模的最小可用场景切入，先通过用例落地核心功能，再逐步扩展领域模型的边界。这种方式能避免过度设计，让模型在真实业务场景中不断打磨完善，而不是一开始就试图构建“完美模型”。

需要特别注意的是：从用例入手≠放弃领域模型。我们不能停留在用例的实现上，而是要把用例作为探索领域的入口——每当完成一个用例，都要反问自己：这个用例背后的核心领域规则是什么？哪些概念是稳定的领域对象？比如从“用户发起退款”用例，我们可以提炼出Order（订单状态校验）、RefundPolicy（退款规则）、RefundRequest（退款申请对象）这些核心领域元素，再把它们整合到领域模型中，反过来优化用例的实现逻辑。

说到底，DDD不是一套必须严格遵守的流程，而是一种以业务为中心的设计思维。只要你的过程始终围绕理解领域、沉淀通用语言、解决真实业务问题，不管是从模型先出发，还是从用例先启动，都是符合DDD理念的合理实践。

内容的提问来源于stack exchange，提问作者choquero70