API-DD library
API-DD Design
Practical guides about conversations, guarantees, and boundaries between modules. If this is your first visit, start with the API-Driven Development manifesto.
The mock that makes a correct refactoring fail
A mock requires Find followed by Save to cancel a booking. A transactional implementation preserves the behavior, but the test fails because it protected the internal path.
The singleton that turns a dependency into global state
A global recorder seems convenient until two tests need different configurations: the singleton hides the required API and shares state among consumers.
The name that forces you to open the implementation
Comparing OrderService.Process with Checkout.Place shows how technical names hide the conversation and how to find more stable vocabulary.
The object that breaks encapsulation just to be created
Decoding JSON directly into User forces fields to be exported and allows invalid states; a transport DTO preserves the invariant and encapsulation.
An API is not HTTP: the same conversation inside a process
Following a cancellation from a handler into two packages separates transport, the application API, and internal collaborations.
The boolean that hides four different results
Reserve bool looks simple until the consumer needs to distinguish a new reservation, a repeated request, out of stock, and a rejection.