DDD - 复杂的 ORM 映射答案

【问题标题】：DDD - Complex ORM MappingDDD - 复杂的 ORM 映射
【发布时间】：2011-11-04 18:34:35
【问题描述】：

我正在编写一个 Java DDD 应用程序，其中已经设计和实现了数据库模型。问题是我的域对象与数据库模型不同，并且 ORM 映射太复杂。这是一个问题：我能用它做什么？ DTO？如果 DTO 看到存储库接口，我如何将 DTO 与存储库和域对象相关联？

谢谢！

【问题讨论】：

我不确定 DTO 在这种情况下会有什么帮助。您能否举一些您遇到困难的映射示例？您可能会惊讶于您可以使数据库模式和域模型有多么不同。也许您需要重新设计域以适应数据库（我知道这不是通常的方式，但有时是必要的）。
好吧，我也面临同样的问题，并且没有现有的 ORM（例如 HIbernate）可以将我的域对象映射到现有的遗留数据库设计。保存每个表单会导致插入多个表并更新其他一些表的某些字段。

标签： java mapping domain-driven-design dto ddd-repositories

【解决方案1】：

Hibernate 对遗留数据库有很好的支持。它远远超出了 class=table 映射。如果您使用额外的 DTO 层，您所指的复杂性不会消失，它只会分散在一层上。将其包含在映射文件中可能更简单。将模型稍微弯曲到数据库模式可能是有意义的，但前提是您会在降低整体复杂性方面看到显着的好处。然后再重构领域模型，以及database。

【讨论】：

【解决方案2】：

许多 ORM 缺乏实现足够好的映射功能。此外，他们引入了概念上的捷径，可能会阻止解决方案与业务保持一致。你的案例就是一个很好的例子。

在您的情况下，我可能会挑战 ORM 的使用。我将在不尝试重用现有数据库模型的情况下实现业务模型，使用 POCO、域服务......对于持久性，鉴于您有 2 个不同的模型，我将使用域模型的依赖注入来管理代码到数据访问层，以防止存储模型污染您的域，然后，在 DAL 中，使用过程代码和微 ORM（如果存储模型复杂，则使用 ORM）实现我自己的映射。它代表着更多的工作，但你会得到一个更好的域。

【讨论】：