Architecture Boundaries Without Boxes
The lesson begins with a checkout service that directly imports a carrier SDK. We follow the dependency from business rule to network client, then introduce a small shipping-policy contract and an adapter at the edge. The diagram names what changed: dependency direction and translation point, not the number of boxes.
The second scene compares a useful Strategy boundary with an unnecessary abstraction around a single stable function. The viewer is asked to list likely changes, failure modes, and the cost of the added interface before choosing a design. Companion material: architecture article, dispatch trace, and Strategy pattern reference.
Related articles
Architecture Boundaries Are Decisions About Change
Use cohesion, coupling, and dependency direction to choose software boundaries that make likely changes easier to contain.
Module Boundaries Should Follow Change
A module groups decisions that are likely to change together and hides details other modules do not need.
C++ Concurrency: Threads and Atomics
How std::thread, std::mutex, and std::atomic work, and the race conditions and memory ordering issues they prevent.
New lessons by email
Get new articles and notes on the systems behind everyday software.
One technical dispatch per week. No noise.
Not started
Sign in to save your learning progress.