我知道 DDD 建议为每个业务操作创建单独的用例。
假设您有一个 Player 聚合。它具有地址值对象。
DDD 不允许在层上创建UpdatePlayer()方法。PlayerApplication相反，我们应该做的是创建企业感兴趣的特定用例。所以，而不是UpdatePlayer()，我想拥有RelocatePlayerTo(Address newAddress)。
如果搬迁后，我发现我在 newAddress 中出错了怎么办？如何调整地址？例如，我拼错了街道名称，或者输入了错误的单位编号。
我应该创建一个新的用例AdjustPlayerAddress吗？还有一个新的 DomainEvent PlayerAddressHasBeenAdjusted？
如果值需要更正怎么办？
这里有一个重要的考虑因素：数据的权威来源是您的模型，还是其他？
例如，我的地址的权威来源是现实世界。正确的拼写取决于各种不受模型控制的事物。在这种情况下，我们真的应该考虑模型作为数据副本保存的内容，这可能是陈旧的。
在这种情况下，实体的 API 将趋于贫乏（真的，您是否要尝试写出地址可能更改的所有不同可能原因？并且您确定我作为主题会去吗？愿意和你分享吗？）
但是，对于相关数据归模型所有的情况，您更有可能创建描述工作中有趣的业务流程的特定流。
有时，更准确地了解正在发生的事情会有所帮助。例如，如果您认为ChangeOfAddress请求是它自己的东西，会发生什么？然后问题就变成了这些信息如何在系统的其余部分移动。
主要思想不是“你不应该使用 CRUD”，而是语言应该与领域的语言相匹配。您的想法拼写的主要来源应该是您的领域专家。