Domain driven design 有界上下文是完整的应用程序吗？

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

这使我认为，绑定上下文基本上只是文件夹，我在其中分组和绑定与应用程序某些特定部分相关的代码。我认为这段代码是由以下内容组成的

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

当然，作为域模型和基础设施，在有限的上下文中适当地分离

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

这让我感到困惑，因为有时候我不想开发成吨的应用程序，我只想开发一个。应用程序的有限上下文划分应该构建一个应用程序，而不是集成多个应用程序

我想@MikeSW说OP提出的两种方法都是有效的。我想问的是关于第三种结构：

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

|_领域
|_基础设施
|_领域
|_基础设施
|_应用
|_介绍

至少对于我所看到的所有应用程序来说，这更有意义。我想要一个应用程序，而不是几个有几个演示文稿的应用程序，但我仍然希望能够打破这个领域，从“绑定无处不在的语言”这样的东西中获益

---

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

归根结底，答案是两者都有。从有界上下文中去掉的重要内容不是你如何构造你的应用程序，而是你有不同的空间，在那里你可以建模与某个上下文相关的特定行为。如何定义这些上下文之间的边界取决于需要解决的问题

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

---

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

有界上下文是代码操作的范围。它依赖于ORM（或非ORM）支持的域模型。它实现了不同种类的服务（域服务和应用程序服务），但其目的是只向其环境公开域服务。DDD是一种面向服务的体系结构，旨在以松散耦合的方式尽可能脱机工作。您可能决定以不同的方式使用您的服务。该解决方案实现了不同种类的组件、不同种类的层、不同种类的项目。我相信最关键的关注点应该是模型，它不应该分布在组件之间。解决方案设计和域模型是正交的。

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

---

无论是指不同的名称空间、解决方案中的不同程序集还是完全不同的项目，您都可以采取任何措施来防止跨上下文直接引用。

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

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

对于每个有界上下文，您可以有一个精简的应用程序层，但仍然有一个表示层。这有时被称为“复合UI”，它本身应该被视为一个单独的BC。如果需要处理诸如身份验证之类的公共逻辑，请在复合UI中创建另一个应用程序服务或facade，并让它在导入之前处理身份验证