Kommunikation zwischen Modulen

Modules with sealed boundaries still need to work together - orders must trigger billing, billing must know a shipment shipped. How they talk determines whether your modular monolith stays modular or slowly fuses back into a tangle. There are two healthy channels - a narrow public API for synchronous calls and domain events for decoupling - and one boundary-killer to avoid at all costs: the shared database.

Synchronous: call the public API

When one module needs an answer right now from another, it calls that module's public API - never its internals (the previous lesson's rule):

// In the orders module - depends only on billing's PUBLIC api
class PlaceOrderService {
    private final BillingApi billing;                 // the front door, an interface

    void placeOrder(Order order) {
        // ... orders' own logic ...
        Invoice invoice = billing.createInvoice(order.id(), order.total());   // ask billing
    }
}

orders depends on the BillingApi interface and its DTOs, nothing more. This is fine for genuine request/response needs, but notice it creates a compile-time dependency from orders to billing. Keep these dependencies acyclic and few - a web of synchronous cross-module calls recreates the coupling you modularized to escape. A tell that you're overusing sync calls: circular dependencies (orders → billing → orders), which are a design smell begging for an event instead.

Asynchronous: publish a domain event

When a module needs to announce that something happened - and doesn't need an answer - it publishes a domain event (the DDD/Observer pattern, now between modules). The publisher doesn't know or care who listens:

// billing publishes a fact - it has no compile-time dependency on who reacts
class InvoiceService {
    private final ApplicationEventPublisher events;
    void finalizeInvoice(Invoice invoice) {
        // ... billing's logic ...
        events.publish(new InvoicePaid(invoice.id(), invoice.orderId()));   // announce
    }
}

// A DIFFERENT module reacts, with NO dependency arrow from billing to it
@Component
class OrderFulfillment {
    @ApplicationModuleListener                          // Spring Modulith's module event listener
    void on(InvoicePaid event) { markOrderReadyToShip(event.orderId()); }
}

This inverts and removes the dependency: billing doesn't import orders; orders listens for billing's event. Events are the primary tool for keeping modules decoupled - use them whenever a reaction is a side effect in another module rather than a value the caller needs back. They also make each module's boundary a clean list of "events I publish" and "events I consume."

The boundary-killer: a shared database

Here's the rule that most often gets broken: modules must not reach into each other's data. If the reporting module runs SELECT * FROM invoices against the billing module's tables, you've created the tightest possible coupling behind everyone's back - billing can't change its schema without silently breaking reporting, and no API or event boundary can save you. The database becomes the shared global state that unravels modularity.

Instead, each module owns its data, and others access it only through the module's API or events:

• Give each module its own tables (and ideally its own schema), and forbid cross-module SQL - enforceable with the same ArchUnit-style checks.
• Need billing data in a report? Call BillingApi, or have reporting build its own read model from billing's events - don't query billing's tables.
• This data ownership is precisely what makes a module extractable into a service later: a service must own its data, so a module that already does is halfway there.