设计方法:用例驱动与域驱动

Question

仅供讨论,对我而言,似乎有两种不同的术语实际上是在说同一件事.这两种设计方法之间是否有任何明显的差异？

Answer 1

用例关注用户,操作和进程.从业务角度来看,这很好,因为每个人都可以看到系统将提供的抽象视图.

DDD专注于创建解决问题的软件.' 谁可以解决这个问题？'和' 他们会遵循什么程序？来之后.

DDD确实在设计过程的早期遇到了核心问题,并帮助您构建解决方案(即识别实体,值对象,存储库,域/应用程序/基础结构服务,有界上下文,规范等).

用例根本不能满足这一需求,或者如何管理您的开发(反腐败层,单独的方式等)

根据我的经验,DDD提供了更大的灵活性(改变了对任何人的要求？),并为您的用例提供了基础.一旦您准备好了域模型,就可以使用与您的域模型连接的控制器/工作流引擎/ UI来实现用例.很多时候,我只是通过构建域模型来确定业务需求的差距.

几年前参加了Ivar Jacobsen的演讲,我也会说DDD更适合敏捷.

Answer 2

对我来说,域驱动设计(DDD)更像是"所有emracassing"; 用例只是一种专注于特定视图的工具:某物如何响应刺激并用于捕捉或记录行为要求.

对我来说,术语"域"是一个加载的 - 它推断出与特定问题区域相关的所有概念的更广泛视图.

在描述域的各个部分如何交互时 - 特别是它们如何响应刺激,那么您​​可以使用用例.

方法如下:用例是4 + 1架构视图模型中的"附加"视图,但它们本身并不是一种设计方法.

另一个区别是DDD通常与面向对象的模型或系统紧密相关; 通过这种方式,DDD捕获/重新呈现(以及其他)系统的结构 - 用例不做的事情.

Answer 3

这是我根据经验的个人解释。

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

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

我个人认为它们可以在一些项目中相互补充，您可以从用例驱动设计开始，并使用 DDD 方法进行详细设计和实现