我承认我仍然是 DDD 的新手,对于 CQRS 更是如此。我也意识到 DDD 和/或 CQRS 可能不是解决所有问题的正确方法。尽管如此,我喜欢校长,但在当前项目的背景下有一些问题。
解决方案是基于当前配置生成性能数据的模拟器。管理员可以创建和修改模拟规范。测试人员设置一些环境条件并运行模拟器。结果被捕获、汇总和报告。
该解决方案由 3 个组件区域组成,每个区域都有自己的用例、领域逻辑和支持数据结构。因此,模块化设计作为一种分离逻辑和分离关注点的方式似乎很有吸引力。
- 第一个领域是允许用户创建和修改规范的管理方面。这将是一个 CRUD 重的“模块”。
- 第二个领域将用于执行模拟。域模型将类似于第一个区域,但针对执行仿真进行了优化,而不是提供方便的模型进行编辑。
- 第三个领域是报告。
我的第一直觉是按照这些思路创建三个模块(程序集)来封装每个区域的领域层。我还应该有三个独立的数据库吗?也许超过三个来支持写入与读取?
我认为这可能是 CQRS 的首选,但不知道如何去做。在我看来,CQRS 建议使用一组移动数据的后端进程。但如果是这种情况,并且数据持久性是跨领域的(正如 DDD 所建议的那样),那么我的数据访问代码不需要了解所有域对象吗?如果是这样,那么拥有单独的模块是否有好处?
最后,我之前没有提到的一点是,规范在发布之前被认为是“草稿”,这使得随后可以用于模拟。我的 PublishingService 需要了解第一个和第二个领域的域模型,以便在它响应 SpecificationPublishedEvent 时,它可以读取规范、翻译模型并将其持久化以供执行。这让我觉得我毕竟没有三个边界上下文。还是我在分析中遗漏了什么?