domain-driven-design - 用于具有多个数据库的复合 .NET 应用程序的 DDD/CQRS

Question

我承认我对于 DDD 来说还是个新手，对于 CQRS 来说更是如此。我还意识到 DDD 和/或 CQRS 可能不是解决所有问题的正确方法。尽管如此，我喜欢这些原则，但在当前项目的背景下有一些问题。

该解决方案是一个基于当前配置生成性能数据的模拟器。管理员可以创建和修改模拟规范。测试人员设置一些环境条件并运行模拟器。结果被捕获、汇总和报告。

该解决方案由 3 个组件区域组成，每个组件区域都有自己的用例、领域逻辑和支持数据结构。因此，模块化设计作为一种分离逻辑和分离关注点的方式似乎很有吸引力。

1. 第一个领域是管理方面，允许用户创建和修改规范。这将是一个 CRUD 重的“模块”。
2. 第二个区域用于执行模拟。域模型将与第一个区域类似，但针对执行模拟进行了优化，而不是提供方便的编辑模型。
3. 第三个领域是报告。

由此我相信我有三个边界上下文，是吗？我有三个清晰的应用程序入口点、三组域逻辑和三个不同的数据模型来支持域逻辑。

我的第一直觉是遵循这些思路并创建三个模块(程序集)来封装每个区域的域层。我还应该拥有三个独立的数据库吗？也许超过三个来支持写入与读取？

我认为这可能是 CQRS 的首选，但我不确定如何去做。在我看来，CQRS 建议使用一组移动数据的后端流程。但如果是这种情况，并且数据持久性是跨领域的(如 DDD 所建议的)，那么我的数据访问代码不需要了解所有域对象吗？如果是这样，那么拥有单独的模块有好处吗？

最后，我之前没有提到的是，规范在发布之前被视为“草稿”，这使得随后可用于模拟。我的 PublishingService 需要了解第一个和第二个区域的域模型，以便当它响应SpecificationPublishedEvent 时，它可以读取规范、转换模型并将其保留以供执行。这让我觉得我毕竟没有三个边界上下文。或者我在分析中遗漏了一些东西？

Answer 1

您可能有一个模块化的 UI，但我在您所描述的内容中没有看到三个独立的域。

首先，在 CQRS 中，报告并不直接涉及域模型，它是独立读取模型的一个方面，它负责呈现针对报告优化的域状态。

其次，仅仅因为域中发生了不同的事情并不一定是将它们彼此隔离的原因。我会读一读蓝色的 DDD 书，以便更好地了解 BC 的样子。

我不太了解您的域名，但我会尝试提供一些一般性建议。

从您谈论 PublishingService 的地方开始。我看到一个规范聚合根，它采用一些可能类似于 CreateNewSpecification、UpdateSpecification 和 PublishSpecification 的命令。

这些事件看起来很相似，而且可能感觉有些多余:SpecificationCreated、SpecificationUpdated、SpecificationPublished。哪种情况很糟糕，但是 CRUD 重型模型没有非常有趣的行为。我还建议找到一种自动化的方法来处理这个聚合上的模型/架构更改，如果您不使用代码生成，或者以不需要您的动态*强调文本*方式处理更改，这将是乏味的每次都建立新的事件。

此外，您可能会考虑不对此类聚合根使用事件源，因为它的 CRUD 量很大。

您描述的第二件事似乎是关于启动模拟，该模拟将根据规范运行并在模拟期间生成数据(我假设)。事件驱动的架构在这里有意义，可以将报告数据的更新与生成数据的过程分离。如果您要生成大量数据进行处理，这会带来巨大的好处。

然而，听起来模拟也不一定是那种可以从事件溯源中受益的 AR。有几个原因:

1. 模拟实际上只需要一个命令，例如 StartSimulation
2. 然后，模拟在其生命周期内生成事件，这些事件代表模拟内部发生的情况
3. 模拟似乎从未收到任何可能取决于模拟当前状态的其他命令
4. 模拟不会同时与多个客户端/用户进行交互，正如我们所指出的，它根本没有真正进行交互

一般来说，领域建模对于每个单独的项目来说都是非常具体的，因此很难为您提供构建领域模型所需的所有信息。这是花费大量时间试图了解用户的需求以及他们试图用软件解决的问题的结果。当您深入了解其流程时，它可能会经历多次改进。