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

Question

我一直在阅读DDD和有限的背景,我想我的想法是错的.起初,我喜欢子域和有界上下文的想法,我理解它是这样的:有一个软件可以开发,但是同时攻击所有的东西太多了,所以我们将它分解成逻辑部分并立即开发每个部分.我们解决的另一个问题是无处不在的语言含糊不清.

这导致我将有界上下文视为基本上只是文件夹,其中我对与应用程序的某个特定部分相关的代码进行分组和绑定.这段代码我认为是由像这样的东西组成的

• 有界上下文的域模型,包括存储库和服务的抽象
• 有限上下文的基础结构层,存储库的实现等

当然,作为域模型和基础设施在有限的上下文中正确地分开.

然而,进一步阅读,似乎每个有界的上下文都是它自己的整个应用程序.有时,似乎每个有界上下文都有自己的应用层.

这让我感到困惑,因为有时候我不想最终开发出大量的应用程序,我只想开发一个应用程序.应用程序的有界上下文划分应该构建一个应用程序,而不是要集成的应用程序.

我似乎在这个问题中@MikeSW说OP提出的两种方法都是有效的.我问的是关于第三种结构:

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

至少对于所有应用程序,我觉得这更有意义.我想要一个应用程序,而不是几个带有多个演示文稿的应用程序,但我仍然希望能够打破"限制无处不在的语言"等领域并从中受益.

那么,有限的上下文是完整的应用吗？或者可以使用有限的上下文,就像我理解并感觉更有用一样？我的方法有什么问题吗？

Answer 1

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

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

您可以为每个有界上下文拥有一个薄应用程序层，但仍然拥有一个表示层。这有时称为“复合 UI”，其本身应被视为一个单独的 BC。如果您需要处理诸如身份验证之类的常见逻辑，请在复合 UI 中创建另一个应用程序服务或外观，并让它处理身份验证，然后再调用外部 BC 的应用程序服务。

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

Answer 2

归根结底，答案是两者兼而有之。从有界上下文中获取的重要信息不是您如何构建应用程序，而是您拥有不同的空间，可以在其中对与某些上下文相关的特定行为进行建模。如何定义这些上下文之间的边界取决于您需要解决的问题。

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

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