15

我一直在阅读有关 DDD 和有界上下文的信息，但我认为我的想法是错误的。起初，我喜欢子域和限界上下文的想法，我是这样理解的：有一个软件要开发，但是一次攻击太多了，所以我们把它分成逻辑部分，一次开发。我们解决的另一个问题是普遍存在的语言的歧义。

这使我将有界上下文视为基本上只是我对与应用程序的某些特定部分相关的代码进行分组和绑定的文件夹。我认为这段代码是由类似的东西组成的

  • 该有界上下文的域模型，包括存储库和服务的抽象
  • 有界上下文的基础设施层、存储库的实现等

当然，域模型和基础设施在有界上下文中正确分离。

然而，进一步阅读，似乎每个有界上下文本身就是一个完整的应用程序。例如，有时似乎每个有界上下文都有自己的应用程序层。

这让我很困惑，因为有时我不想最终开发大量的应用程序，我只是开发一个。应用程序的限界上下文划分应该是构建一个应用程序，而不是很多应用程序需要集成。

我似乎在@MikeSW 说OP 提出的两种方法都有效的地方提出了这个问题。我要问的是第三种结构：

<bc 1>
 |_ domain
 |_ infrastructure
<bc 2>
 |_ domain
 |_ infrastructure
|_ application
|_ presentation

至少对于我所看到的所有应用程序来说，这更有意义。我想要一个应用程序，而不是几个具有多个演示文稿的应用程序，但我仍然希望能够打破诸如“限制无处不在的语言”之类的领域和利益。

那么，有界上下文是一个完整的应用程序吗？还是可以像我理解的那样使用有界上下文并感觉更有用？我的方法有什么问题吗？

4

4 回答 4

5

领域层通常是程序中最复杂的部分，并且由于业务需求和重构也可能经常发生变化。因此，您通常不希望将其直接暴露给您的表示层或其他有界上下文。如果您觉得可以公开它，则可能是您的应用程序逻辑或用例方法混合到您的领域层中，或者您的程序不够大或不够复杂，需要多个 BC 开始。否则，我会在每个 BC 中包含应用程序层，以保护域模型的完整性并仅公开需要从用例角度调用的命令。

我想要一个应用程序，而不是几个具有多个演示文稿的应用程序，但我仍然希望能够打破诸如“限制无处不在的语言”之类的领域和利益。

您可以为每个有界上下文创建一个瘦应用层，但仍然拥有一个表示层。这有时被称为“复合 UI”，它本身应该被视为一个单独的 BC。如果需要处理鉴权等通用逻辑，可以在复合 UI 中创建另一个应用服务或门面，让其处理鉴权，然后再调用外部 BC 的应用服务。

我认为您在书籍和网络上看到的大多数示例都被过度简化了，因为它们每个物理运行的应用程序有 1 个 BC（并在它们之间执行某种网络通信），而在现实世界中您可能有一个复杂的您需要拆分为单独的逻辑单元的应用程序，但除非需要，否则不要将它们作为单独的进程运行。

于 2017-08-10T02:11:46.780 回答
3

归根结底，答案是两者兼而有之。远离有界上下文的重要一点不是你如何构建你的应用程序，而是你有不同的空间来建模与某些上下文相关的特定行为。如何定义这些上下文之间的边界取决于您需要解决的问题。

使用命名空间（文件夹）来定义有界上下文并没有错。就像你说的大多数时候你只是在写一个应用程序。您还可以通过为每个上下文设置单独的项目来定义有界上下文。在这种情况下，您的表示层将引用它需要的项目。

编码 DDD 有很多正确的方法。你应该问自己“我这样做是不是遵循了核心原则”

于 2015-02-18T20:10:13.043 回答
1

有界上下文描述了完整解决方案的一个子集，并且该上下文中的所有内容都服务于该上下文。因此，imo，每个上下文都有自己的域，因此它可以是单独的应用程序或只是同一项目的子系统。“上下文”的重点是无处不在的语言直接应用于该上下文。例如，帐户上下文中的用户可能与销售上下文中的用户完全不同。每个“用户”将具有不同的能力，并在每个上下文中遵循不同的规则。每个上下文都需要与任何其他上下文隔离，并且不允许共享引用（除非它是通过“共享”上下文）；任何通信都应通过位于该上下文之上的服务进行调解。上下文甚至不必遵循 DDD 即可“

无论您需要做什么来防止跨上下文的直接引用都很好，无论这意味着不同的命名空间、解决方案中的不同程序集还是完全不同的项目。

于 2016-08-24T20:37:37.360 回答
0

有界上下文是代码运行的范围。它依赖于域模型，可以由 ORM 支持（或不支持）。它实现了不同类型的服务（域服务和应用程序服务），但其目的是仅将域服务暴露给其环境。DDD 是一种面向服务的架构，旨在尽可能离线并以松耦合的方式工作。您可以决定以不同的方式使用您的服务。该解决方案实现了不同类型的组件、不同类型的层、不同类型的项目。我相信最关键的注意力必须关注模型，它不应该分布在组件之间。解决方案设计和领域模型是正交的目的。

于 2015-04-14T21:50:13.510 回答