FREE LESSON · Applications & software architecture · 1 OF 4
Software Cohesion, Coupling and Architecture
Architecture is change made legible — Cohesion, coupling, and domain boundaries
A module should own a coherent reason to change.
Cohesion keeps related rules and data together. Coupling measures how many assumptions cross a boundary. A good boundary exposes a stable capability, hides volatile implementation detail, and keeps its invariants enforceable in one place. Layers, components, and services are tools—not goals.
The best boundary follows the shape of decisions and ownership, not the current folder tree.
Keep pricing policy out of the delivery adapter
A checkout handler can parse transport input and call a subscription capability. Eligibility, proration, and renewal rules belong in a domain boundary that can be exercised without HTTP or a particular database. This does not require grand frameworks; it requires dependencies pointing toward the rule owner.
Separate essential policy from accidental delivery mechanisms so each can evolve and be tested honestly.