Modular Monolith?

You're absolutely right. Within a modular monolith, the "modules" (represented by services in our example) interact through direct method calls, not over network boundaries like URLs. This is a key difference and a major advantage of the modular monolith approach, especially in terms of performance and simplicity.

Let's clarify the distinction:

Modular Monolith (Current Situation):

• Interaction: Your CustomerService (or repository if you skip the service layer) directly instantiates and calls methods on the AccountService and ContactService (or repositories). These are regular Java method calls within the same application. There are no HTTP requests or network communication involved. This is why the single database query approach is so much more efficient within the monolith.

Microservices (Future Scenario):

• Interaction: When you extract the Accounts and Contacts modules into separate microservices, the CustomerService (which would likely reside in its own microservice as well) will then need to communicate with the Accounts and Contacts microservices over the network. This is typically done using:

  • REST: HTTP requests to specific URLs exposed by the microservices.

  • gRPC: A high-performance RPC framework that uses protocol buffers.

  • Message Queue (Asynchronous): For less time-critical operations, services can communicate asynchronously through a message queue (e.g., Kafka, RabbitMQ).

Why the Change Matters:

• Performance: Network communication is inherently slower than in-process method calls. This is why moving to microservices can introduce performance overhead. However, this overhead is often acceptable in exchange for the benefits of microservices (scalability, independent deployments, etc.).

• Complexity: Microservices introduce significant complexity in terms of service discovery, inter-service communication, distributed transactions, and fault tolerance. This is why it's generally recommended to start with a modular monolith and migrate gradually.

• Testing: Testing microservices requires mocking or stubbing out the network calls to other services.

Your Initial Question Revisited:

You were concerned about making multiple calls (which you correctly identified as a potential performance issue). Within the modular monolith, the direct method calls are generally not a significant performance concern (unless the logic within the services themselves is very inefficient). The database calls are the primary concern, which is why the single query approach is often preferred within the monolith.

In summary: In your current modular monolith setup, you are not making URL calls. You are making direct method calls within your application. When and if you move to microservices, then you will need to use URLs (or gRPC or messaging) for inter-service communication. This is a fundamental shift in architecture and a key reason to carefully consider the trade-offs before jumping to microservices.