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.
7 articles
Development
Notes on implementation practice, C#, .NET, testing, validation, and maintainable code.
2 articles
Latest articles
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