Recommendation concerning persistence setup in a Spring Boot / Modulith project

[KUnger-Spg]

I'd like to ask the community about your experiences and preferences whether you provide

• a single db single schema
• a single db with multiple schemata (one per module)
• multiple dbs (one per module)

for your Spring Boot / Modulith application!

As we do not want references to entities of another aggregates/modules (no fk-references, no @ManyToOne),
how do you ensure these constraints.

Do you use ArchUnit test rules or do you also have those rules also expressed in the DB (different users for different schemata, different DBs)?

Looking forward for your feedback!

[ghferrari]

Hi @KUnger-Spg, I've asked myself the same question and like you, I'd be very interested to hear from others what approach they take. I'm happy to share my current view but I'm no expert and I'm hoping others say more.

One comment on your statement that:

we do not want references to entities of another aggregates/modules (no fk-references, no @manytoone)

All the official examples that I've checked (e.g. the RESTBucks app) use a single db schema and allow inter-model references between modules. For example, in the RESTBucks application, the LineItem class in the orders module references the Drink class in the drink module. This is achieved by placing these model classes in the top level folder of the module, hence they appear in the module's top-level API interface. An alternative way of achieving the same thing would be to move model classes into a public subpackage of their module and using a Spring Modulith NamedInterface to allow them to be referenced from other modules that need them.

However, as you suggest, there may be some motivation to use concepts from DDD to ensure e.g. that foreign aggregates are referenced only by id. The RESTBucks application uses jmolecules to enable this - for example, the reference to Drink in the LineItem class references it via the jmolecules Association type. This SpringIO session goes into more detail.

For myself, the conclusion I've reached (pending input from others with more expertise) is that it depends on why one is using Spring Modulith. If you simply want to organise your code by feature module, take some easy steps to reduce coupling between modules, and take advantage of nice Spring Modulith features like limiting inter-module connection points and using ApplicationEvents, then it's fine to use a single DB schema and have inter-module model dependencies. But if you want to separate modules out which might potentially become their own microservice, then it may be worth going for a greater level of decoupling, which would involve having no inter-module model dependencies, no inter-module foreign keys in the database, and allowing only async communication between modules via Events or synchronous communication by a module's public service API. By removing inter-module model relationships and their underlying foreign key constraints, you'd be a big step closer to extracting those modules into a separate microservice. And you could do this either within the same database schema or by using a schema-per-module pattern. However, be aware that having separate databases makes it more difficult to achieve cross-module queries or transactions.

[ghferrari]

I enjoyed this talk CodeCamp on Moduliths, which discusses how to decouple modules.

[odrotbohm]

I largely agree with this. Let me try to summarize some things mentioned and add a few details.

• We want modules to be loosely coupled. Thus, want the data owned by the modules to be loosely coupled, too. That, quite fundamentally, incentivizes avoiding foreign key relationships as we'd prevent the module referred to from freely managing its data. I quite generally think that there's value in – for example – orders referring to customer 47, without data for customer 47 being available at some point. That at least allows us to determine that these orders belong to the same customer.
• A natural consequence of that train of thought is that one would avoid foreign key relationships between aggregates. That said, I think it's okay to relax that constraint for in-module aggregate relationships if there's good cause to do so.
• A similar approach can be argued on the type level: cross-module relationships should be established by identifier references, primarily between domain model elements. As a convenience mechanism, it's fine to accept full type (aggregate) references in a model elements API if it's directly translated into an identifier reference or association. RESTBucks' LineItem's constructor is such an example. I use that approach regularly if the calling code is likely to have a fully loaded aggregate available anyway, and I want to avoid having to extract an identifier on the call site. It's purely cosmetics, though. If you want simpler rules, stick with the “identity references only”.
• If modules are integrated through bean references, it's likely they have to expose domain types or DTOs. Unless the project development indicates a module being a candidate for extraction any time soon, I usually default to even domain types exposed directly, but in a read-only state. That means that any state changing methods stay package private. Alternatively, interfaces can be introduced. I'd only resort to mapping to DTOs and back to avoid unnecessary complexity. The coupling introduced by that approach can be used to our advantage, as refactoring tools might help us propagate the changes through the system. At the very least, the compiler indicates which places we need to adapt.