对大型Hibernate模型进行分区以管理模式依赖关系

我们正在考虑将hibernate表拆分为包或域（发票、销售等），主要用于依赖关系管理问题

当然，它不会很好地分解，所以我们不确定如何处理跨域的关系。对于这一点，有一个新的实体注释是很好的，但同时一个想法是制作模型的多个副本，其中关系注释的方式存在一些变化，以“剪掉松散的一端”。这些修改后的实体可能需要在它们不属于的其他模型中设置为“只读”。此外，我们将继续使用现有的完整模式一段时间，因为我们过渡到使用较小的应用程序

例如，大多数表应该完全存在于某个模型中；但是如果Domain1.Table1与Domain2.Table2相关，那么您将在另一个域中为每个域创建一个只读副本。副本会将其域中的其他关系更改为“死胡同”（可能通过将关系链接替换为整数fk引用属性）

关键是，我们希望有一些方法来管理我们的maven构建，这样当有人更改表上的属性时，我们就可以声明对该域模型的依赖关系，这样我们就可以减少需要重建的应用程序的数量。（我们有严格的部署停机窗口）

哦，所有域都必须使用相同的java包，以与我们的遗留EJB持久性工具兼容

---

这就是我的想法。有什么建议/反馈/意见吗？谢谢

您建议将相关表的实体复制到所需的域（不是它的域）中，然后将其自身的域依赖项更改为“死胡同”即整数FK值，必要时可用于查找

我的建议是，你应该在每个域的边缘这样做，不要复制任何东西。因此，如果Domain1.Table1与Domain2.Table2相关，那么它只是有一个FK，int字段，可能称为table2Id。这将在每个域的边缘创建死胡同，而不需要交叉和复制

不过我得问问

你确定你有多个域吗

---

您的问题的根源似乎来自这样一个事实：您的数据是相关的，这向我表明它们是同一领域的一部分。例如，您将销售和发票视为单独的域，但它们可能都共享客户参考。这一切都让我觉得它是属于我的。一些项目/行业的领域很大，为了方便和简单而将它们拆分通常最终会成为一个错误，并且常常会增加意想不到的复杂性。例如，如果您需要执行销售查询，该查询应包含发票的引用，但现在您必须执行单独的发票查询，这会使您的API客户端的使用量有点大。

不，它实际上是一个域；这就是问题所在——任何分裂都是人为的，都有一定程度的痛苦。看起来我们有两个选择-目前的方式只是一个大的“模型”依赖-每次任何部分的变化，我们所有的应用程序都需要重建。另一个极端是每个表的依赖关系——需要仔细检查客户机，以确定要声明哪些依赖关系，但我认为，当模型的某些部分发生变化时，我们会有更小的重新构建集。我希望找到一些中间路线，但还没有找到任何东西。