How do you join data from different module if needed?

[duhjent]

Hi, @kgrzybek
As you said, shared data between modules is not allowed, neither a transaction that spans multiple modules. What if you needed to return the participants of a particular meeting with their login and email?
The first thing that comes to mind is duplicating this data, when creating a meeting participant. But this way can lead to data inconsistency and the only way to keep duplicate data in sync is sending events (for example, when someone changes his/her email, then publishing an event to update the other module's data), but this brings additional complexity. Are there other ways to accompilish the task?

[AndreiGanichev]

Hi, @duhjent
There was the same question in comments of Modular Monolith: Architecture Enforcement article. Here is Kamil's answer:

There is no simple answer for that question because it depends on context and requirements.
Solutions:

1. Integrate modules by events. You can send an event like PremiumUserActivated and "Article" module will save this information for teaser/full article rule execution
2. Execute 2 calls from GUI/API layer - one to "Articles" module, one to User module and combine data. It is called Composite View Pattern.
3. Create separate module for reporting purposes. Get data by subscribing to events or using ETL mechanism (batch loads).
4. Make a direct call from one module to another as last resort
5. Integrate modules by shared database as last, last, last, last, last resort ;)

I would also advice to read Modular Monolith: Integration Styles article of the series to understand pros and cons of these approaches.

[magik110417]

Hello,

I have the exact same situation. I have Multiple modules in my application with same database. Each module has it's own schema. For example, Customers module has a database schema named [customers] and Ordering module has [ordering] schema. Now I have 2 different usecases where I need to join the data from different module

1. When return list of Customers, return Number of Orders placed by each Customer.
2. When Creating a new Order for Customer, check if that Customer (with customer id) exist in the system.

What I am thinking to do is to implement views for the use cases. For example, create a view called [custeroms][v_orders] that will return the limited data about the order from [ordering].[orders] table.

Similary, for second usecase, create a view called [ordering][v_customers] that will return limited data about Customer from [customers].[Customers] table.

I know this type of integration has high coupling between modules on Database level, but since I am not directly querying other modules data, rather I am going through the database view, maybe this approach may not be as bad? Also we are not planning to move to micro-service architecture for this application in the future, so I think this coupling maybe ok?

Any thoughts or suggestions?

[musjj]

This part also puzzles me. It seems to me that with a modular monolith DDD, retrieving data from other bounded contexts is very cumbersome, often requiring you to duplicate data from one BC to another (because direct calls are "bad"). Or requires the resource/API to manually call and compose the necessary application services together.

With a traditional DDD, retrieving data from other BCs can be done liberally and conveniently. For example, through a REST API like in Vaughn Vernon's example from his book.

Is there really no such equivalent in a modular monolith that doesn't require you to resort to direct calls?