我假设这个问题只会在使用jOOQ的LiquibaseDatabase时出现，它会模拟liquibase迁移以生成代码。

• 使用test containers based code generation instead。之前的博客文章使用Flyway，但它对Liquibase的作用是一样的。这意味着在构建这两个模块的过程中，您将拥有一个正在运行的数据库示例，在生成jOOQ代码时，该示例将是最新的。这也消除了任何与模拟相关的问题，例如允许您使用RDBMS的供应商特定功能。
• 将数据库变更管理和模式提取到另一个模块中，使模式成为“全局的”，而不是依赖于模块。无论如何，你的外键多少暗示了模式是全局的。关系模型实际上并不是以树的形式定向的。它是一个图。迟早，你会有一个从A到B的键，你的依赖关系将变成循环的。
• 保持纯粹的“模块化”，使模式独立，去除键。当然，数据完整性是一件好事，因此为此付出的代价很高，但它会解决您眼前的问题。
• 从jOOQ的代码生成中删除密钥，并声明一个synthetic foreign key in jOOQ's code generation（尽管B在生成过程中仍然需要知道A）
• 在为模块B生成代码时，为A * 和 * B运行liquibase迁移。这样，B就可以再次获得所有信息。

选择哪一个是一个主观的选择，没有明确的答案，但至少，这给了你选择。