API Module §
Public workshops:
- Designing microservices: responsibilities, APIs and collaborations DDD EU, June 2-3, Antwerp, Belgium Learn more
Contact me for information about consulting and training at your company.
Also known as §
Context §
Forces §
Problem §
How to reduce build time coupling between modules?
Solution §
Each domain module consists of an API module and an implementation module. e.g. customers-api and and customers
A domain module’s clients only depend on the API module. Clients are tested using mocks/stubs of the API module.
Implementation module depends on the API module.
interface CustomersApi {
CustomerDTO getCustomer(String customerId);
}
record CustomerDTO(...) {}
Variation §
A module can have multiple API modules in accordance with the Interface segregation principle.
Resulting context §
Benefits §
Changing the module’s implementation will not require clients to be rebuilt/retested.
- Using mocks/stubs in tests can simplify testing.
Drawbacks §
- Fast deployment pipeline
- Unlike when using microservices: Additive changes to an API, which cause (kinda-transitive) clients to be rebuilt/retested.
- Changing a widely used API module, e.g.
money-api, might require many modules to be rebuilt/retested.
- Risk that the mock/stub doesn’t match the real implementation. e.g. Unhandled enum value (in result DTO) should break the build
Premium content now available for paid subscribers at 
