Architecture Practice
This section contains notes on system architecture, solution structure, boundaries between components, and the practical consequences of architectural decisions.
The focus is on architecture as something that supports change, testing, maintainability, and clear reasoning about a system.
Notes and reflections on system structure, boundaries, maintainability, and long-term technical direction.
Local Reasoning Is an Architectural Superpower
A discussion of local reasoning and why maintainable systems allow developers to understand behavior without traversing large portions of the codebase. Good architecture reduces cognitive load by keeping ownership, behavior, and responsibilities visible and close together.
Good architecture allows developers to understand behavior without touring the entire system.Read article
Why Good APIs Feel Predictable
A practical exploration of why predictable APIs are easier to learn, easier to trust, and easier to evolve. Good APIs reduce cognitive load by making behavior discoverable, consistent, and unsurprising.
An API succeeds not when callers can eventually figure it out, but when they rarely need to figure it out in the first place.Read article
The Best Senior Developers Reduce Cognitive Load
A practical exploration of how experienced developers reduce cognitive load through clearer ownership, discoverability, and architecture that is easier to reason about over time.
Great senior developers are not the ones who can personally survive the most complexity. They are the ones who reduce how much complexity everyone else must survive.Read article
The Difference Between Workflow and Business Rules
A practical exploration of the difference between workflow coordination and business rules — and why systems become harder to understand when orchestration layers gradually absorb business meaning.
Workflow coordinates. Business rules decide.Read article
When DTOs Start Becoming Your Domain Model
A practical exploration of how DTOs gradually absorb validation, workflow logic, and business meaning — and why systems become harder to understand when transport models start replacing the domain itself.
A DTO should carry data across a boundary — not become the place where business meaning lives.Read article
Architecture Should Make Wrong Code Feel Wrong
A practical exploration of how good architecture guides developers toward healthy decisions, makes misplaced responsibilities easier to recognize, and reduces the chance that harmful design choices feel natural or convenient.
Good architecture does not only make the right code possible. It makes the wrong code feel out of place.Read article
When Abstractions Become Noise
An exploration of how unnecessary abstractions increase cognitive load, dilute responsibility, and create accidental complexity, and how meaningful abstractions should protect real architectural boundaries rather than speculative flexibility.
Every abstraction should earn its place.Read article
Testing Architecture Through Behavior, Not Structure
An exploration of how architectural quality is reinforced through behavior-focused testing rather than tests tightly coupled to internal implementation details, with emphasis on maintainability, refactoring safety, mocks, integration tests, and sustainable system evolution.
In extreme cases, the architecture itself begins adapting to the tests rather than to the actual needs of the system.Read article
When Validation Has No Clear Owner
A practical look at why validation often becomes scattered across UI, application, domain, and persistence layers, and how assigning each kind of validation a clear owner makes systems easier to change and reason about.
The question is not whether validation should exist in several places, but whether each validation rule has the right owner.Read article
When the UI Knows Too Much
A practical look at how UI code can gradually take ownership of business and workflow decisions, and how keeping the UI focused on presentation and interaction makes systems easier to change, test, and reason about.
The UI should reflect the state of the system, not secretly define the rules of the system.Read article
Application Services Should Orchestrate, Not Own Everything
A practical look at how application services can become overloaded, and how keeping them focused on use case orchestration makes layered systems easier to change, test, and reason about.
After the change, the application service should read more like a use case and less like a collection of implementation details.Read article
The Cost of Unclear Boundaries in Layered Architecture
Layered architecture is not only about projects and folders. This article looks at how unclear boundaries make systems harder to change, test, explain, and refactor — and why important decisions should have one clear owner.
A system can look layered and still behave like a tightly coupled system.Read article
Keeping Filtering in the Repository Layer
Filtering often begins in the UI layer, but this can lead to duplication and inconsistent behavior over time. This article explores why filtering drifts into the UI and how moving it into the repository layer can provide a more stable foundation.
The UI expresses what the user is trying to achieve. The repository determines how the data is selectedRead article