我正在尝试使用Sparx Enterprise Architect来设计一个数据模型，该模型最终将出现在MySQL数据库中。
我的第一种方法是数据模型图，它可以用来生成DDL（或者通过逆向工程反过来）。
这很有效，但一位同事指出了一个障碍：我们打算使用ORM（几乎可以肯定是Hibernate）将表映射到Java类。他的评论是“数据库优先”的方法将排除使用良好的OO技术，如继承。
这似乎是一个很好的观点，但我想知道是否有任何限制。如果我从头开始使用类图而不是数据模型图，是否有一种方法可以在此模型中包含所有必要的Hibernate注释，配置等？如果我以后需要对特定于数据库的功能（如约束、触发器等）进行建模，那么在模型中，鉴于类图并不是真正针对此类事物，那么所有这些在模型中是否成为可能？
我更喜欢先对数据库进行建模。数据库是业务中最有价值的部分，应用程序逻辑只是操作业务数据的接口。
由于数据库往往比应用程序技术更持久，因此最好提前设计它，因为设计通常由数据关系和数据查询模型驱动。
大多数 ORM 旨在将域对象建模为现有模式，这是 ORM 工具任务，用于处理任何可能的数据库模式映射问题。
对于快速原型设计，我可能会考虑从域对象生成我的模式，但在设计大型企业系统架构时，这种方法是不理想的。
Hibernate只提供有限数量的DDL功能，我不喜欢失去额外的数据库特定功能，如PosgreSQL域，而不是触发器，具体化视图或MySQL触发器。
像 Flyway 这样的工具最适合用于自动执行架构迁移过程。
让我问一个问题来回答：如果你想建造一所房子，你会先建房子，然后做一个蓝图，还是先制定计划？:)
软件开发就是要逐步降低抽象。我们从一个非常抽象的项目想法开始，然后提出一些要求（这显然有点不那么抽象），然后架构，设计和精细地进入编码级别（最低的抽象）
数据模型是尽可能低的抽象级别（可直接映射到 DDL）的模型，因此这是您要做的最后一件事。
域类模型是数据库的更高抽象。它甚至是Hibernate层的抽象，因为它也位于抽象的实现级别。
因此，我首先肯定会使用类和 OO 的全部功能对域进行建模。尝试使实现独立于类模型。不要假设JAVA，Hibernate，DB，任何东西，而是专注于你的领域逻辑。做一种“乌托邦”的域模型，逻辑上结构完美的域类。
然后使用相应的转换从此模型派生Hibernate层和DB本身。
