模型和限界上下文如何映射到代码库 DDD 中？答案

【问题标题】：How Models and Bounded-Contexts are mapped into the codebase DDD?模型和限界上下文如何映射到代码库 DDD 中？
【发布时间】：2019-12-05 13:59:02
【问题描述】：

模型和有界上下文在概念上是：

型号：

描述领域选定方面的抽象系统并可用于解决与该领域相关的问题。

有界上下文：

一个词或语句出现的环境决定了它的意思。

但我有问题：

提前致谢。

注意：请随意用一些框架、Django、Axon..等来陈述你的答案。

【问题讨论】：

【解决方案1】：

两者的关系是包容关系，即 Bounded-Context 有一个或多个模型？

我想你可以这么说，但有界上下文 (BC) 只有一个模型，对象根据 BC 的通用语言 (UL) 命名。

模型和 BC 都属于解空间。

在问题空间中，您有域和子域。

在解决方案空间中，您有 BC（理想情况下与子域相关的 1:1）。您为子域建模，每个子域模型都有一个 BC。

但是，例如，您可以只用一个模型对整个域建模，这样整个域的解决方案空间中就只有一个 BC。在这种情况下，您有一个与许多子域相关的 BC。这个 BC 将是一个单体应用程序。

另一个例子，一个子域与许多 BC 相关，当您将子域拆分为几个“部分”并为每个“部分”建模时，就会发生这种情况。所以你会有很多子域的模型。这样，在解决方案空间中，您就有许多子域的 BC，即解决子域问题的许多应用程序。

当根据 UL 术语进行的划分模糊时，子域和 BC 之间会出现 1:N 或 N:1 关系的情况。

据我了解，DDD 概念应该是可识别的（在某种程度上）通过代码库，对于聚合、实体、事件、命令...等，但如何将模型和有界上下文映射到代码库？例如一个模型只是一组一个或多个聚合，还是别的什么？限界上下文是命名空间还是还有什么？

BC 是一个软件系统，一个自主的应用程序。而一个模型就是BC的源代码。但在 DDD 中存在另一个概念：模块，即一组有凝聚力的领域对象。它比 BCs 更薄。

所以你有，从宽到小：

解决方案 --> BC --> 模块 --> 聚合 --> 实体和值对象

【讨论】：

【解决方案2】：

这是基于我对课程的理解......意见可能会有所不同。

模型在您的代码中不是一回事，但如果做得好，它就是代码。这是您从业务的知识危机中得出的，并尝试在代码中捕获。为整个业务设计一个模型通常是一件愚蠢的事情。所以你有一个模型在...中有效的上下文。
有界上下文是模型有效的上下文。出于几个原因，这很有价值。它允许我们管理模型的范围和复杂性。模型只有在帮助我们解决业务问题时才有用。为此，我们需要能够在脑海中保留某种形式的信息，以便我们能够理解。这就是语言的用武之地。语言、聚合等对于该上下文是有效的。我喜欢在这里举一个例子。电子商务结账中的产品不同于从仓库中挑选的产品。他们可能共享一些概念，但有些概念与上下文无关。应在上下文图中捕捉它们之间的关系。

【讨论】：