1

根据为 DDD 或六边形架构记录的推荐实践 - 域模型应该与与实际使用的技术（表/列名称、连接等、JPA 注释）更相关的数据模型表示分离。这里的一个实际问题是——你如何在这个模型中做乐观版本控制之类的事情？假设您有一个域服务可以读取-->更新-->保存在域模型上。现在 JPA 实体可能有一个无法向上传递的版本列。因此，当保存调用到达存储库并且存储库基本上再次进行（模型->实体）转换和读取+更新时，它将无法判断最初读取的是哪个版本的实体。
次要问题是对此的性能考虑，涉及此处的一些额外阅读

4

2 回答 2

2

你可以做不同的事情：

  • 放宽域模型应该从持久性模型中分离出来的规则。没有人说 DDD 有应该严格遵守的“固定规则”。这意味着您将在域中使用相同的 JPA 实体，按照 DDD 规则而不是 JPA 规则对它们进行建模。因此，每个字段都没有获取/设置，所有 ValueObject 都没有嵌入实体等等。但是，正如您肯定知道的那样，如果域很复杂，您必须努力避免 JPA 陷阱。
  • 在将 JPA 实体转换为域实体之前，将其存储在缓存中。它看起来很愚蠢，但最终持久层和域层之间的分离允许您以对您有用的任何方式实现存储库。因此，如果您的 JPA 实体有一个版本，我想到的管理它的最简单方法是在存储库的实现中拥有一种缓存。然后你可以这样进行：
    1. 读取 JPA 实体
    2. 将其存储在缓存中
    3. 发送生成的域实体以进行更新
    4. 取回更新的域实体
    5. 更新缓存中的 JPA 实体
    6. 存储它，将版本处理留给 JPA
  • 忽略 JPA 的东西并直接使用 SQL。您已经拥有域实体，编写 SQL 使您可以自由地根据需要完美调整代码，而无需 JPA 层的开销。您仍然可以使用缓存解决方案，为每个 Id 存储您已阅读的实体的版本，并以与以前相同的方式使用它。

对于在项目中具体使用 DDD，没有灵丹妙药的解决方案。这取决于您的需求和愿望。

我应该快点完成吗？我可以在域转换层的持久性上投入一点时间吗？

以后有人使用/更改此代码吗，如果我不将“锁”放在上面，那会做奇怪的事情吗？

我是否正在尝试创建一个纯 DDD 实现？

我应该放宽一些规则，在我的项目中或我的团队中慢慢引入 DDD？

于 2020-11-27T08:57:18.087 回答
0

有不同的方法可以做到这一点。这主要取决于您的应用程序/层在架构中的位置。大多数情况下，与实体模型通信的应用程序/层处于基础级别。当没有任何目的时，您没有义务制造分离。通信证明将始终是与该层对话的层，因此我认为不需要再创建一个转换。您可以只传递实体模型/实例数据。

于 2021-06-04T20:31:26.970 回答