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

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

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

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

第一个方面是管理方面，允许用户创建和修改规范。这将是一个积垢严重的“模块”。

第二个区域将用于执行模拟。域模型将类似于第一个区域，但针对执行模拟进行了优化，而不是提供方便的模型进行编辑。

第三个领域是报告。

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

我的第一反应是按照这些思路创建三个模块（程序集），封装每个区域的域层。我还应该有三个独立的数据库吗？可能有三种以上的软件支持写与读

我想这可能是CQR的首选，但不确定如何进行。在我看来，CQRS建议使用一组后端进程来移动数据。但如果是这样，并且数据持久性是跨领域的（正如DDD所建议的），那么我的数据访问代码不需要了解所有域对象吗？如果是这样，那么使用单独的模块是否有好处

---

最后，我在前面没有提到的一点是，规范在发布之前都被视为“草稿”，这样就可以进行模拟了。我的PublishingService需要了解第一个和第二个领域的域模型，以便在响应规范PublishingDevent时，能够读取规范、转换模型并将其保存以供执行。这让我觉得我根本没有三个边界上下文。或者我在分析中遗漏了什么？

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

首先，在CQRS中，报告不是直接涉及域模型的问题，它是分离读取模型的一个方面，负责呈现为报告而优化的域状态

第二，仅仅因为域中发生了不同的事情并不一定是将它们彼此分开的理由。我会通读这本蓝色的DDD书，更好地了解BCs的样子

我不太了解你的领域，但我会尝试给出一些一般性的建议

从你谈论出版服务的地方开始。我看到了一个规范聚合根，它接受了一些可能类似于CreateNewSpecification、UpdateSpecification和PublishSpecification的命令

这些事件看起来很相似，可能感觉多余：规范已创建、规范已更新、规范已发布。这很糟糕，但是积垢重的模型没有非常有趣的行为。我还建议找到一种自动化的方法来处理此聚合上的模型/模式更改，如果您不使用代码生成，或者以动态的*强调文本*方式处理更改，而不需要每次构建新事件，那么这将是一件乏味的事

您也可以考虑不要使用事件源来处理这样的聚合根，因为它是如此重的。 您描述的第二件事似乎是关于启动一个模拟，该模拟将基于一个规范运行，并在模拟期间生成数据（我假设）。在这里，事件驱动的体系结构可以将更新报告数据与生成数据的过程解耦。如果要处理大量数据，这将带来巨大的好处

然而，听起来模拟也不一定是从事件源中获益的AR类型。有几个原因：

模拟实际上只需要一个命令，类似于StartSimulation

然后，模拟在其生命周期内生成事件，这些事件表示模拟内部正在发生的事情

模拟似乎从未收到任何其他可能取决于模拟当前状态的命令

模拟不会同时由多个客户机/用户进行交互，正如我们所指出的，它根本不会真正进行交互

---

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

发布服务又是什么？这是执行模拟的服务吗？或者发布服务与事件发布者是同一件事？很抱歉延迟回复，这个主题已经过时了，所以我现在才看到您的回复。不过，这是一个快速的跟进。当您说“我看到一个规范聚合根需要几个命令…”时，“它需要几个命令”是什么意思？