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

Question

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

这促使我将有界上下文视为基本上只是文件夹，其中我对与应用程序的某个特定部分相关的代码进行分组和绑定。这段代码我认为是由

之类的东西组成的

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

当然，在有限的背景下正确地划分域模型和基础设施。

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

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

我似乎this question其中@MikeSW表示OP提供的两种方法都是有效的。我要问的是关于第三种结构：

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

至少在所有应用程序中，我认为这更有意义。我想要一个应用程序，而不是几个带有多个演示文稿的应用程序，但我仍然希望能够打破领域和好处，例如＆＃34;限制无处不在的语言＆＃34;。

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

Answer 1

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

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

有很多正确的方法来编写DDD。你应该问问自己＆＃34;我是否按照这种方式遵循核心原则＆＃34;

Answer 2

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

  

我想要一个应用程序，而不是几个带有多个演示文稿的应用程序，但是我   仍然希望能够打破这样的领域和好处   “限制无处不在的语言”。

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

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

Answer 3

有界上下文描述了完整解决方案的一个子集，该上下文中的所有内容都为该上下文提供服务。因此，imo，每个上下文都有自己的域，因此它可以是一个单独的应用程序，也可以只是同一个项目的子系统。 ＆＃34;背景＆＃34;是无处不在的语言直接适用于该背景。例如，“帐户”上下文中的“用户”可能表示与“销售”上下文中的“用户”完全不同的内容。每个＆＃34;用户＆＃34;将具有不同的功能并在每个上下文中遵循不同的规则。每个上下文都需要与任何其他上下文隔离，并且不允许共享引用（除非它通过共享＆＃39;上下文）;任何通信都应通过位于该上下文之上的服务进行调解。上下文甚至不必遵循DDD以符合DDD标准＆＃34;因为每个上下文可以遵循它自己的方法（例如，域驱动，数据驱动等）。上下文只是概述业务逻辑部分的孤岛。

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

Answer 4

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