仅供讨论，对我来说，似乎有两种不同的术语实际上是在说同样的事情。这两种设计方法之间是否有任何明显的差异？
答案 0 :(得分：23)
用例专注于用户，操作和流程。从业务角度来看，这很好，因为每个人都可以看到系统将提供的抽象视图。
DDD 专注于创建解决问题的软件。 '谁可以解决这个问题？'和'他们会遵循什么流程？'之后会出现。
DDD 确实在设计流程的早期遇到了核心问题，并帮助您构建解决方案（即识别实体，值对象，存储库，域/应用程序/基础结构服务，有界上下文，规范等）。
用例根本不满足此要求，或者如何管理您的开发（反腐败图层，单独方式等）
根据我的经验，DDD提供更多灵活性（改变任何人的要求？），并为您的用例提供基础。在您的域模型到位后，可以使用与您的域模型连接的控制器/工作流程引擎/ UI 来实施用例。很多时候，我只是通过构建域模型来确定业务需求的差距。
几年前参加了Ivar Jacobsen的演讲，我也说DDD更适合敏捷。
答案 1 :(得分：8)
对我来说，域驱动设计（DDD）更像是“所有emracassing”;用例只是一种专注于特定视图的工具：某物如何响应刺激并用于捕捉或记录行为要求。
对我来说，术语“域”是一个加载的 - 它可以推断出与特定问题区域相关的所有概念的更广泛视图。
在描述域的某些部分如何交互时 - 特别是它们如何响应刺激，那么您可以使用用例。
就方法而言：用例是4+1 Architectural View Model中的“附加”视图，但它们本身并不是一种设计方法。
另一个区别是DDD通常与面向对象的模型或系统紧密相连;以这种方式DDD捕获/表示系统的结构（除其他外） - 用例不做的事情。
答案 2 :(得分：3)
用例驱动方法可以正常工作，客户已经告诉过您需要解决的所有问题。这在面向服务的公司中是可能的。 当您拥有同一产品的多个客户端时，很难管理。这通常发生在产品开发公司。 在这种情况下，（产品驱动型公司）DDD 会派上用场。您使用DDD开发产品（您将其称为基础）。然后检查，是否适用于新客户端的所有用例，如果没有，则为基于客户端的更改形成基础层。
答案 3 :(得分：2)
这是我根据经验的个人解释。
用例驱动设计使用用例作为工具来发现实体，界面，交互消息以及如何进行某些业务操作的工作流程。这通常用于更多分析或设计阶段，以收集或理解需求并建立一些初始设计。另一方面，DDD更侧重于实施，并且强烈关注域实体和上下文。在定义模型（例如类，接口）和定义其边界，聚合，操作和特定于域的逻辑方面，它侧重于比用例更多的细节。它通常遵循一些关于如何在实施中处理它们的标准实践。
当您处理针对特定域（例如会计，工程）的项目时，DDD更适合您可以预见业务中的某些或大多数模型可能具有复杂的相互关系和体现逻辑。在用例驱动设计或DDD之间进行选择还取决于领域专家的可用性。如果您有业务需求的利益相关者（只有一些访问域专家），那么与DDD相比，使用案例驱动的设计更合适。如果您没有领域专家直接参与开发，那么采用DDD的风险很高。该项目。
我个人认为他们可以在一些项目中相互补充，在这些项目中，您可以从用例驱动设计入手，并使用DDD方法进行详细设计和实施
答案 4 :(得分：1)
域驱动设计本质上试图表现得就像你事先知道所有可能的用例一样。根据定义，“问题”域是一组被视为该域成员的特定问题。
答案 5 :(得分：1)
我不是这方面的专家，这些术语可能是模糊的，对不同的人来说意味着不同的东西。但..
我会说域设计就是现有系统（基于纸张，手动，无论如何），软件模拟系统中的实际实体。因此，在图书馆系统中，您可以查看图书馆，看到有书籍，书架，橱柜和房间。基于此，您可以在软件中对真实域进行建模。
对于用例，您可以从“我们要做什么”开始。可能您的模型中不需要不同的房间，因为在用例中不需要它们。这使得您的系统更简单（并且更不容易出错），但如果您没有对“真实世界”进行建模，那么您将失去一些灵活性。