Approach
How I Approach Architecture Reviews
An architecture review should not be an abstract judgement of whether a codebase follows a preferred pattern. It should help a team understand where change is becoming harder, where risks are accumulating, and which improvements are worth making next.
My focus is on practical architecture and maintainability for long-lived .NET applications: responsibility placement, boundaries, infrastructure dependencies, testability, and the everyday cost of change.
The review starts with the change the system needs to support
I do not start by looking for a specific architecture style. I start by asking what the application needs to keep doing, what is likely to change, and where the team currently feels friction.
A design decision that looks acceptable in isolation may still be costly if it makes common changes spread across too many places. Likewise, a decision that looks imperfect may be perfectly reasonable if it keeps the important parts of the system clear and stable.
What I look for
The review is centered on whether the codebase makes important decisions visible, local, and safe to change.
Responsibility placement
Are business rules, workflows, infrastructure concerns, and UI behavior placed where they belong, or are they mixed in ways that make future changes harder?
Architecture boundaries
Do boundaries protect intent, or do they exist mostly as folders, layers, or project names without clear responsibility?
Infrastructure leakage
Are framework, database, API, or UI details leaking into application code in ways that make the core workflow harder to understand?
Change locality
When a normal business change is needed, can it be made in a small and understandable area, or does it require coordinated edits across unrelated parts of the codebase?
Testability
Do tests protect behavior and design intent, or do they mostly mirror implementation details and make refactoring harder?
Incremental improvement
Can the system be improved in small, safe steps, or does every improvement appear to require a disruptive rewrite?
The output should be useful, not theatrical
A good review should not end with a large theoretical redesign that the team cannot realistically act on. The output should make the current situation clearer and identify practical next steps.
Typical recommendations may include clarifying boundaries, moving responsibilities closer to the workflow they belong to, reducing convenience dependencies, improving test seams, or separating infrastructure concerns from application decisions.
I prefer smaller corrections over dramatic rewrites
Many maintainability problems do not require a full rewrite. They require better placement of decisions, clearer seams, and a more deliberate direction for future changes.
When a rewrite is genuinely worth considering, that should be based on specific risks and constraints, not frustration with the existing codebase alone.
What a review can help clarify
- whether architecture concerns are real or mostly cosmetic
- which parts of the system create the most change risk
- where business logic or workflow intent has become hidden
- whether infrastructure dependencies are shaping the application too much
- which improvements can be made incrementally
- what should probably be left alone for now
Interested in a .NET Architecture Review?
Send a short description of the application, architecture decision, or maintainability concern, and I can assess whether a focused review would be useful.