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

Question

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

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

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

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

从这我相信我有三个边界上下文，是吗？我有三个明确的入口点，三组域逻辑和三种不同的数据模型来支持域逻辑。

我的第一本能是遵循这些线条并创建三个封装每个区域的域层的模块（程序集）。我是否应该有三个独立的数据库？也许超过三个支持写与读？

我收集这可能是首选的CQRS，但我不知道如何去做。在我看来，CQRS提出了一组移动数据的后端过程。但是如果情况如此，并且数据持久性是交叉的（如DDD所示），那么我的数据访问代码是否需要知道所有域对象？如果是这样，那么分离模块是否有好处？

最后，我之前没有提到的是，规范被认为是“草案”，直到发布，然后可用于仿真。我的PublishingService需要知道第一个和第二个领域的领域模型，以便当它响应SpecificationPublishedEvent时，它可以读取规范，翻译模型并将其保留以供执行。这让我觉得我毕竟没有三个边界上下文。或者我在分析中错过了什么？

Answer 1

你可能有一个模块化的用户界面，但我没有看到你所描述的必须有三个单独的域。

首先，在CQRS报告中并不直接涉及领域模型，它是分离的Read Model的一个方面，负责呈现为报告优化的域状态。

其次，仅仅因为你在域中发生的不同事情并不一定是将它们彼此分开的理由。我会通过阅读蓝色的DDD书籍来更好地感受BCs的外观。

我不太了解您的域名，但我会尽量给出一些一般性建议。

从谈论PublishingService的地方开始。我看到一个规范聚合根，它需要几个可能看起来像CreateNewSpecification，UpdateSpecification和PublishSpecification的命令。

事件看起来很相似，可能会感到多余：规范创建，规范更新，规范发布。哪一种吸引人，但一个CRUD重型模型没有非常有趣的行为。我还建议找到一种自动化的方法来处理这个聚合体上的模型/模式变化，如果你不使用代码生成，或者以不需要你的动态强调文本的方式处理变化，这将是单调乏味的。每次构建新事件。

另外，您可能会考虑不使用事件采购来处理这样的聚合根，因为它的CRUD很重。

您描述的第二件事似乎是开始一个模拟，它将根据规范运行并在模拟过程中生成数据（我假设）。事件驱动的体系结构在这里有意义，以便将正在生成数据的进程的报告数据更新。如果您正在生产大量的数据进行处理，这将带来巨大的收益。

然而，它听起来并不像一个模拟必然是受益于事件采购的AR。一对夫妇的原因：

1. 仿真真的只需要一个命令，它是像StartSimulation
2. 模拟然后产生了它的生命时间的事件，其代表的是与模拟
3. 模拟内部不发生似乎永远收到任何其他命令，可能取决于目前的模拟状态
4. 模拟不是由多个客户端/用户同时交互，并且正如我们指出它根本没有真正交互

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