使用 EF 遵循 DDD 时持续存在流程步骤和工件答案

【问题标题】：Persisting Process steps and artifacts when following DDD with EF使用 EF 遵循 DDD 时持续存在流程步骤和工件
【发布时间】：2018-10-08 17:46:42
【问题描述】：

我们有一个应用程序，其中一个功能是生成输出，准确地说是 PowerPoint 幻灯片。生成输出的过程在创建最终输出之前要经过多个步骤。

我们要求记录每个步骤以及可选地在每个步骤生成的工件（二进制文件），最终帮助最终用户和支持诊断问题。

对于应用程序的其余部分，我们一直在遵循 DDD 方法，这是一段旅程，但我对这种要求的方法存在冲突。

我最初的方法是让用户的每个请求都生成一个 PowerPoint 作为 DocumentRequest，这将是一个聚合根。我的问题是如何表示这些步骤及其相关的工件。然后对这些步骤进行单独的聚合，因为我看不到任何将通过请求强制执行的不变量。 DocumentRequest 不会有 Steps 的集合。每个步骤都有一个返回请求的外键。

我能想到的壁橱相似之处是 VSTS 表示发布或构建的方式。每个构建/发布都包含步骤，每个步骤都可以选择下载工件或钻入文本日志。

【问题讨论】：

没有业务规则/不变量和很少协作/并发访问的域不是您可以充分利用 DDD 战术模式的上下文。我可能会重新考虑在这里使用它们。

标签： domain-driven-design aggregate

【解决方案1】：

不是 DDD 专家，但我同意 - DocumentRequest 在我看来也不是一个好的聚合根。我在问自己一个问题——可以在不知道生成过程所经过的步骤的情况下定义DocumentRequest 吗？对我来说当然可以。可以在没有Result这一代的情况下定义吗？再次，它可以。

看起来流程本身非常重要 - 您希望能够查看不同步骤的工件。所以我会考虑将DocumentGenerationProcess（或者如果你能找到一个更好的术语）作为聚合根。它将包含每个步骤引用的工件的步骤，并且可能是最终结果（PowerPoint 幻灯片）。

另一种建模方式 - 将 DocumentGenerationProcessResult 作为聚合根。通常它将包含生成的文档（如果结果是成功的）。如果用户想深入了解详细信息，DocumentGenerationProcessResult 将引用带有步骤/工件的 GenerationProcess。

【讨论】：