Practice
This section contains curated notes and articles on software architecture, development practice, and technical leadership.
The focus is on practical experience from designing, building, maintaining, and leading software systems over time.
Architecture
Notes on system structure, boundaries, maintainability, dependency direction, and architectural decision-making.
13 articles
Development
Notes on implementation practice, C#, .NET, testing, validation, and maintainable code.
3 articles
Latest articles
Extracting a Small Provider-Agnostic Mailing Library
A practical reflection on extracting a small provider-agnostic mailing library that separates application intent from delivery mechanism. The article shows how SMTP, mailto, null, and recording senders can share the same abstraction while product-specific workflows remain in the consuming applications.
The common part is not the provider. The common part is the message.Read article
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
Why CancellationToken Should Flow Through the System
A practical look at why cancellation should be treated as part of an operation itself, how CancellationToken propagation affects responsiveness and resource usage, and why incomplete cancellation flow often creates hidden reliability and maintainability problems.
Cancellation belongs to operation lifetime, not to every function call.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
Using async and await Deliberately
A practical look at when async and await are useful in C#/.NET, when they add unnecessary complexity, and how to use asynchronous code deliberately in UI, web, repository, and application-service code.
The goal is not to make every method return `Task`. The goal is to make waiting visible where waiting is real.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