we have a project structure like the following
"module-shared" module depends on "module-database" module and some other modules depend on "module-shared" but no other module depends on "module-database".
All the DML SQL scripts are stored in "module-shared" but DDL are stored in "module-database".
- The advantage of this design is that
we don't have to release the database if changes are around DML in "module-shared" and use database integration tests to make sure they are still compatible.
- The disadvantage is that
this creates some confusions on the versions. For example you can have "module-shared" 2.3.1 depends on "module-database" 1.4.2 and eventually we will forget which version is compatible with which.
Would it be a better design if we have a "module-database" which contains both DDL and DML (and all other database operations if any) and module-shared contains everything it had except database operations?
What's your experiences on having multi-tier architectures? do you always use modules to segregate tiers? Do you have experiences where you may have DAO and Services in the same module? If you do, where did you keep the DDL schema scripts?
UPDATE: forget to mention that the DDL is versioned using database script versioning system such as flyway. So that all DDL changes are incremental
Note: e.g. a module could be gradle module, maven module, etc.
Note: I am trying my best to be not biased while asking this question. So please assume that I don't have any preference on either solution. :)