domain-driven-design - 有界上下文是一个完整的应用程序？

Question

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

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

该有界上下文的域模型，包括存储库和服务的抽象

有界上下文的基础设施层、存储库的实现等

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

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

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

我好像 this question @MikeSW 说 OP 提出的两种方法都是有效的。我要问的是第三种结构:

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

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

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

Answer 1

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

I want one app, not several apps with several presentations, but I still want to be able to break the domain and benefit of things like "bounding the ubiquitous language".

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

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