3

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

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

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

  1. 第一个领域是允许用户创建和修改规范的管理方面。这将是一个 CRUD 重的“模块”。
  2. 第二个领域将用于执行模拟。域模型将类似于第一个区域，但针对执行仿真进行了优化，而不是提供方便的模型进行编辑。
  3. 第三个领域是报告。
由此我相信我有三个边界上下文，是吗？我有三个明确的应用程序入口点、三组域逻辑和三种不同的数据模型来支持域逻辑。

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

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

最后，我之前没有提到的一点是，规范在发布之前被认为是“草稿”，这使得随后可以用于模拟。我的 PublishingService 需要了解第一个和第二个领域的域模型，以便在它响应 SpecificationPublishedEvent 时，它可以读取规范、翻译模型并将其持久化以供执行。这让我觉得我毕竟没有三个边界上下文。还是我在分析中遗漏了什么？

4

1 回答 1

1

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

首先，在 CQRS 报告中，报告不是直接关注领域模型，它是分离读取模型的一个方面，负责呈现针对报告优化的领域状态。

其次，仅仅因为您在域中发生了不同的事情并不一定是将它们彼此分开的理由。我会阅读蓝色的 DDD 书，以便更好地了解 BC 的外观。

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

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

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

此外，您可能只是考虑不为这样的聚合根使用事件溯源，因为它是如此繁重的 CRUD。

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

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

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

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

于 2011-06-07T17:49:45.777 回答