Question about references to objects from different module

[josealbertocoronado]

Hi.
I've got a question about how the different modules are structured in the solution.
So we have modules for Flight, Booking and Passenger (well, and Users but that's not relevant for my question).
My point is how you define these modules and how you reference each others.
Let me put an example.
A Booking depends on a Flight and a Passenger. Let's say we want to add a new feature in Booking module which is GetBookingById and the response must contain booking details plus fight details: do we need to make a call to Flight service for it and then aggregate booking and flight in the same response object?
With that context, wouldn't make more sense Flight and Booking live in the same module? That way a simple b.Include(b => b .Flight) would make life easier.

Another argument would be: a Booking is a secondary entity, it cannot exist if we don't have a flight, so is it the same boundaries and therefore same module?

Sorry if too generic, just trying to understand whether you've organized the solution like that to illustrate how the architecture works or because is the correct thing to do in this domain?

[meysamhadeli]

Hi,

For the first part of your question, I used a dedicated database for each module instead of having a single database with different schemas for each module. Most of the time, a single database with separate schemas per module is sufficient when we don’t have a large application and know we won’t be moving to a microservices architecture soon. This approach is more straightforward and easier to maintain. However, on the other hand, we can separate databases for each module when we know the system is large, and the likelihood of migrating to microservices is high. Although this setup is more complex, it simplifies things when we eventually move to microservices, as each module will already have its own database, reducing additional work.
For this specific case, I agree that having multiple databases adds unnecessary complexity, and it's better to use a single database with the schema approach. I will implement this in issue #19 .

Note: To retrieve data from one module for another, I currently use REST or gRPC, which is not the most performant approach. I've created issue #18 to implement a gateway pattern for synchronous communication between modules using in-memory calls with MediatR, allowing autonomous operation for each module.

Regarding the booking bounded context, it currently manages book reservations and will handle payments in the future. The separation of the boundaries here is just an example, and I’ve considered each boundary responsible for its own dedicated business functionality.

[josealbertocoronado]

Hi.
Thanks for answering. That makes total sense.
Curious to see that gateway pattern implementation. I guess you pretty much mean use MediatR to run a query that goes to a different module and contains the data in the response?
I thought using gRPC is correct? Is it just purely about performance? With gRPC latency is pretty much nothing, so maybe all good?

[meysamhadeli]

Hi. Thanks for answering. That makes total sense. Curious to see that gateway pattern implementation. I guess you pretty much mean use MediatR to run a query that goes to a different module and contains the data in the response? I thought using gRPC is correct? Is it just purely about performance? With gRPC latency is pretty much nothing, so maybe all good?

Hi,

Yes, with the gateway pattern, I will use MediatR to handle requests for retrieving data from the modules. Using gRPC here adds complexity and overhead on top of the network. With the gateway pattern, we have an interface that leverages MediatR, and in the future, when we move to microservices, we can modify the gateway pattern implementation to use gRPC or REST instead of MediatR (in-memory calls). For now, I prefer to use MediatR to reduce complexity and network latency. Additionally, we have the flexibility to change the implementation in the future.

[josealbertocoronado]

How you avoid circular dependencies with that approach?
I mean, let's say you need an endpoint to retrieve a Booking including Flight details.
And separately let's say you need an endpoint to retrieve a Flight with al the Bookings for it.

With gRPC you can achieve that easily, but with Mediatr approach Flight module would need a reference to Booking module, and the other way around. How do you make that work? You would maybe need to create separate projects containing only the interfaces?

[meysamhadeli]

Yes, with using mediatr, we will have coupling between module. it's a trad offs between using grpc or mediar. and each one have pro and cons.
with grpc we have autonomous modules and also we have more complexity and overhead top of network.
with mediatr we have coupling between modules and have simpler structure, more easy to maintain and without performance overhead.
both of this approach are common and depend of applications and comparing trad offs, we can choose which one is appropriate for our system.
I agree, maybe have autonomous module has more advantage compare to a latency with grpc. and after migrating to microservice we have very less breaking change in this part with grpc.
I will follow this article for implementation of gateway pattern:
https://www.kamilgrzybek.com/blog/posts/modular-monolith-integration-styles

[josealbertocoronado]

Excellent, thanks for clarifying.
Looking forward to see the implementation to understand how your organise projects to avoid these circular dependencies.

Thanks!