API Module
Public workshops:
- Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow JNation, May - Coimbra, Portugal Learn more
- 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.
Until May 16th, enroll for $95 in my virtual bootcamp, distributed data patterns in a microservice architecture
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 
