0

Let's assume we have a modular monolith architecture with 2 modules A and B both relying on two separate DB schemas. If module A needs data from module B, he will get it through a communication canal (synchronous or asynchronous), but never querying directly the DB schema of B.

However, if this decoupling is required at the application level, is it required also at the DB level?

By example, is it acceptable to have a table in schema A having a foreign key reference to a table in schema ?

If this is the case, how to identify the entities that are shared between module A and B ? I mean, does the ID(db primary keys) can be passed around between modules?

Thanks a lot

Fede
  • 804
  • 1
  • 10
  • 21

1 Answers1

0

After some reading I arrived at the following conclusion:

The best practices is to have one database(schema) by module and having each module accessing only is own database (or schema), this to ensure no coupling between modules. Modules should share data by publishing events/messages that can be handled by the other modules.

Then to answer my questions, decoupling is not only required at the application level, but also at the db/data level. There should not be any relation/foreign key between tables of different modules, but data duplication across the db of different modules is acceptable.

Also it is totally fine to share entity Ids across modules, where each module store the Id and eventually other entity information in his own database/schema.

If any cross modules data aggregation is required for reporting/analysis purpose, this must be done in a separate database from the one accessed by the modules (specific reporting database).

Fede
  • 804
  • 1
  • 10
  • 21