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