DDD / 聚合根 / 版本控制
DDD / Aggregate Root / Versioning
我们通常如何处理聚合根的版本控制？
我是这么想的（我在调查设计领域）。
进行版本控制的一种方法是使用显式方法在现有版本的基础上创建新版本。例如，Study（聚合根）。
所以最初我们有一个聚合根，其根实体是 Study with (business) 键 "ABC"，版本“1”。
通过在研究中调用方法"newVersion()"，将创建该研究和属于同一聚合根的所有其他实体的副本。
所以基本上，版本控制是通过创建一个单独的实例（聚合根）来完成的。 ID 是复合的（业务密钥 + 版本）。
我们怎么知道它是不是一个分支？或者它只是一个版本？ （1.1？或 2）。我想，这个简单的规则会起作用：如果没有关联的其他版本，那么它是 "one version up" (2)；如果已经有另一个版本，那么它就是一个分支 (1.1)。
另一个问题：噪音。
但这意味着，我们无法处理/修改现有版本。每次我们想要对我们的对象进行修改时，我们都必须创建一个新版本。每次？？？嗯....听起来不对。
或者...我们可以根据标志（活动/不活动，或已发布/未发布）制定这样的规则。如果flag是"not-active"，我们可以直接修改AR，不需要创建新版本。如果该标志处于活动状态，我们必须：(a) 首先将其设置为 "not-active"，然后修改.... 或 (b) 创建一个新版本并处理该版本（最初设置为 "not-active" ).
关于这件事你有什么想法/经验要分享吗？
我想你在研究这个问题时会觉得有些混乱，因为有两个截然不同的概念在起作用：
- 版本控制作为支持乐观并发的并发控制机制
- 版本控制作为一个明确的领域概念
支持乐观并发的版本控制
乐观并发是指允许同时启动两个事务，但如果它们都尝试修改同一个数据项，则只允许第一个事务继续进行。有关不同锁定策略的概述，请参阅 Concurrency Control。
总而言之，您将版本控制留给了持久性技术，因为版本的目的是检测对持久层的同步写入。
使用此模式时，通常甚至不保留旧版本的副本，但作为审核 trail/change 日志当然可以这样做。
版本控制作为一个明确的领域概念
根据您的问题，以及支持潜在分支策略的需要，听起来版本控制是您领域中的一个显式领域概念 - 即 "Version" 的概念是您的领域专家谈论的话题，并且使用版本是无处不在的语言的重要组成部分。
但是，您提出了一些不同的概念，表明该领域需要进一步探索：
- 版本分支
- 用户自定义版本naming/tagging（但仍连接到'chain'个版本）
- 显式版本更改（用户请求）与隐式版本更改（每次更改时自动）
- 如果我正确理解您的意图，通过显式版本控制，当前 'active'/'live'/'tip' 版本是可变的并且可以在不跟踪更改的情况下进行修改，直到用户'commits' 它 - 它变得不可变，并且创建了一个新的 'live' 可变版本。
探索此版本时可能会出现的其他一些概念：
- 分支合并（一旦你分裂了两个分支，如果你想把它们重新组合起来会怎样？）
- 回滚 - 如果您有旧版本，您是否支持 'undoing' 一项或多项更改？
鉴于以上所述，您可能还会从版本控制系统集中工作的方式（例如 subversion) and distributed (e.g. git and mercurial）中找到一些见解，因为它们提供了一个活跃的版本跟踪工作模型，混合了可变和不可变元素。
这里的开放性问题告诉我，您需要与您的领域专家一起更详细地探讨这个问题。使用 DDD 有时很容易迷失在您 可以 做什么，但我强烈建议您尝试并理解您 需要 做什么。
您的 users/domain 专家如何看待这个世界？他们希望能够执行什么样的操作？这些操作实现其初始目标的目的是什么？您的目标是将这些问题的答案提炼到一个模型中，该模型可以有效地封装他们使用的流程。
编辑以考虑建模
根据您的评论 - 我的第一反应是在考虑修改后的问卷时质疑 'version' 这个词的解释。事实上，我很想挑战 template/survey 关系的建模。考虑一组可能的实体：
模板
- 定义问卷中的问题集
- 支持操作：
- 开始调查
- 修改模板中的问题、选项等各种操作
调查
- 调查将拥有自己的问卷，而不是引用 'live' 模板
- 当您调用 Template.StartSurvey 时，它 returns 一个预先填入模板问题列表的调查
- 调查还支持修改问题 - 但这不会更改创建它的模板
- 与模板不同，调查还维护一个记录答案列表，并提供设置答案的操作
- 它可能还包括一个生命周期状态，其中在某些状态下允许回答问题，但是一旦'submitted'你就不能修改答案（只能猜测这个）。
在这个世界上，调查是'stamped out'从模板里出来的，然后过着独立的生活。调查中的问卷可以任意修改，不影响模板。
这里的权衡是，如果您确实修改了模板，none 已经根据它创建的调查将得到更新 - 但听起来这对您来说可能更安全？
您还可以支持将调查转换回模板的操作，这样如果您喜欢修改后的调查的外观，您可以 'templatize' 它可以用于未来的调查。
我们通常如何处理聚合根的版本控制？
我是这么想的（我在调查设计领域）。
进行版本控制的一种方法是使用显式方法在现有版本的基础上创建新版本。例如，Study（聚合根）。
所以最初我们有一个聚合根，其根实体是 Study with (business) 键 "ABC"，版本“1”。
通过在研究中调用方法"newVersion()"，将创建该研究和属于同一聚合根的所有其他实体的副本。
所以基本上，版本控制是通过创建一个单独的实例（聚合根）来完成的。 ID 是复合的（业务密钥 + 版本）。
我们怎么知道它是不是一个分支？或者它只是一个版本？ （1.1？或 2）。我想，这个简单的规则会起作用：如果没有关联的其他版本，那么它是 "one version up" (2)；如果已经有另一个版本，那么它就是一个分支 (1.1)。
另一个问题：噪音。
但这意味着，我们无法处理/修改现有版本。每次我们想要对我们的对象进行修改时，我们都必须创建一个新版本。每次？？？嗯....听起来不对。
或者...我们可以根据标志（活动/不活动，或已发布/未发布）制定这样的规则。如果flag是"not-active"，我们可以直接修改AR，不需要创建新版本。如果该标志处于活动状态，我们必须：(a) 首先将其设置为 "not-active"，然后修改.... 或 (b) 创建一个新版本并处理该版本（最初设置为 "not-active" ).
关于这件事你有什么想法/经验要分享吗？
我想你在研究这个问题时会觉得有些混乱，因为有两个截然不同的概念在起作用：
- 版本控制作为支持乐观并发的并发控制机制
- 版本控制作为一个明确的领域概念
支持乐观并发的版本控制
乐观并发是指允许同时启动两个事务，但如果它们都尝试修改同一个数据项，则只允许第一个事务继续进行。有关不同锁定策略的概述，请参阅 Concurrency Control。
总而言之，您将版本控制留给了持久性技术，因为版本的目的是检测对持久层的同步写入。
使用此模式时，通常甚至不保留旧版本的副本，但作为审核 trail/change 日志当然可以这样做。
版本控制作为一个明确的领域概念
根据您的问题，以及支持潜在分支策略的需要，听起来版本控制是您领域中的一个显式领域概念 - 即 "Version" 的概念是您的领域专家谈论的话题，并且使用版本是无处不在的语言的重要组成部分。
但是，您提出了一些不同的概念，表明该领域需要进一步探索：
- 版本分支
- 用户自定义版本naming/tagging（但仍连接到'chain'个版本）
- 显式版本更改（用户请求）与隐式版本更改（每次更改时自动）
- 如果我正确理解您的意图，通过显式版本控制，当前 'active'/'live'/'tip' 版本是可变的并且可以在不跟踪更改的情况下进行修改，直到用户'commits' 它 - 它变得不可变，并且创建了一个新的 'live' 可变版本。
探索此版本时可能会出现的其他一些概念：
- 分支合并（一旦你分裂了两个分支，如果你想把它们重新组合起来会怎样？）
- 回滚 - 如果您有旧版本，您是否支持 'undoing' 一项或多项更改？
鉴于以上所述，您可能还会从版本控制系统集中工作的方式（例如 subversion) and distributed (e.g. git and mercurial）中找到一些见解，因为它们提供了一个活跃的版本跟踪工作模型，混合了可变和不可变元素。
这里的开放性问题告诉我，您需要与您的领域专家一起更详细地探讨这个问题。使用 DDD 有时很容易迷失在您 可以 做什么，但我强烈建议您尝试并理解您 需要 做什么。
您的 users/domain 专家如何看待这个世界？他们希望能够执行什么样的操作？这些操作实现其初始目标的目的是什么？您的目标是将这些问题的答案提炼到一个模型中，该模型可以有效地封装他们使用的流程。
编辑以考虑建模
根据您的评论 - 我的第一反应是在考虑修改后的问卷时质疑 'version' 这个词的解释。事实上，我很想挑战 template/survey 关系的建模。考虑一组可能的实体：
模板
- 定义问卷中的问题集
- 支持操作：
- 开始调查
- 修改模板中的问题、选项等各种操作
调查
- 调查将拥有自己的问卷，而不是引用 'live' 模板
- 当您调用 Template.StartSurvey 时，它 returns 一个预先填入模板问题列表的调查
- 调查还支持修改问题 - 但这不会更改创建它的模板
- 与模板不同，调查还维护一个记录答案列表，并提供设置答案的操作
- 它可能还包括一个生命周期状态，其中在某些状态下允许回答问题，但是一旦'submitted'你就不能修改答案（只能猜测这个）。
在这个世界上，调查是'stamped out'从模板里出来的，然后过着独立的生活。调查中的问卷可以任意修改，不影响模板。
这里的权衡是，如果您确实修改了模板，none 已经根据它创建的调查将得到更新 - 但听起来这对您来说可能更安全？
您还可以支持将调查转换回模板的操作，这样如果您喜欢修改后的调查的外观，您可以 'templatize' 它可以用于未来的调查。