Design patterns 设计方法：用例驱动与领域驱动

只是为了讨论，在我看来，两个不同的术语实际上在说同一件事。这两种设计方法之间有什么实质性的区别吗？

对我来说，领域驱动设计（DDD）更像是“全emcompassing”；其中as用例只是一个专注于特定视图的工具：某个事物如何响应刺激，并用于捕获或记录行为需求

对我来说，术语“领域”是一个负载的领域——它推断出与特定问题领域相关的所有概念的更广泛的观点

当描述域的各个部分是如何相互作用的——特别是它们如何对刺激做出反应时，您可以使用用例

就一种方法而言：用例是中的“附加”视图，但它们本身不是一种设计方法

---

另一个区别是，DDD通常与面向对象的模型或系统紧密相关；通过这种方式，DDD捕获/响应（除其他外）系统的结构-有些事情用例不做。

这是我基于经验的个人解释

用例驱动的设计使用用例作为工具来发现实体、接口、交互消息和关于如何执行特定业务操作的工作流。这通常用于更多的分析或设计阶段，以收集或理解需求并建立一些初始设计。另一方面，DDD更倾向于实现，重点关注域实体和上下文。在定义模型（如类、接口）和定义其边界、聚合、操作和特定于领域的逻辑方面，它比用例更关注细节。它通常遵循一些关于如何在实施中接近它们的标准实践

当您在处理针对特定领域（如会计、工程）的项目时，DDD更合适，您可以预见业务中的一些或大多数模型可能具有复杂的相互关系和体现的逻辑。在用例驱动设计或DDD之间进行选择还取决于领域专家的可用性。如果您有具有业务需求的利益相关者（只有一些访问领域专家的权限），那么与DDD相比，用例驱动设计更适合。如果您没有直接参与项目开发的领域专家，则采用DDD的风险很高

---

我个人认为，在一些项目中，它们可以相互补充，在这些项目中，您可以从用例驱动的设计开始，并使用DDD方法进行详细的设计和实现，用例关注用户、操作和流程。从业务的角度来看，这很好，因为每个人都可以看到系统将提供什么的抽象视图

DDD专注于创建解决问题的软件。“谁能解决这个问题？”和“他们将遵循什么过程？”随后会出现

DDD在设计过程的早期真正触及核心问题，并帮助您构建解决方案（即识别实体、价值对象、职责、域/应用程序/基础设施服务、有限上下文、规范等）

用例根本不能满足这一点，或者如何管理您的开发（反腐败层、单独方式等）

根据我的经验，DDD提供了更大的灵活性，并为您的用例奠定了基础。一旦你有了你的域模型，就可以使用与你的域模型连接的控制器/工作流引擎/UI来实现用例。通常，我仅仅通过构建领域模型就发现了业务需求中的差距

---

几年前，我参加了Ivar Jacobsen的一次演讲，我还想说DDD更适合敏捷。

领域驱动设计基本上试图表现得好像你事先知道所有可能的用例一样。根据定义，“问题”域是被视为该域成员的一组特定问题。

如果产品只有一个客户，并且客户已经告诉您需要由产品解决的所有问题，那么用例驱动的方法可以很好地工作。一般来说，这在面向服务的公司是可能的。 当同一产品有多个客户时，管理起来就很困难了。这通常发生在产品开发公司。

---

在这种情况下（产品驱动型公司），DDD将派上用场。您使用DDD（您称之为基础）开发产品。然后检查，新客户的所有用例是否都适用，如果不适用，则在基础上形成一层，用于客户特定的更改。

我不擅长这方面，这些术语可能很模糊，对不同的人意味着不同的事情。但是

我会说域设计是指存在一个现有的系统（基于纸张的、手动的等等），软件对系统中的实际实体进行建模。所以在一个图书馆系统中，你看到一个图书馆，里面有书、书架、橱柜和房间。基于此，您可以在软件中对真实域进行建模

---

对于用例，您从“我们正在尝试做什么”开始，可能是您的模型中不需要不同的房间，因为用例中不需要它们。这使您的系统更简单（且不易出错），但如果您不对“真实世界”建模，则会失去一些灵活性。

确切地说，DDD是指尽可能准确地对商业世界建模。如果该模型是准确的，那么支持用例和支持变更就变得容易多了。但是，即使你的模型第一次不完美，一个干净的模型要比一个缺少这样一个基础的解决方案更容易改变和修复。在最近的一次谈话中，Eric Evans强调了