Q26 proof · Multi-layered .NET: loose coupling and separation of concerns

26. Multi-layered .NET applications

Answer as submitted

“Yes — layered .NET solutions with explicit separation of concerns are exactly how I structure applications.”

Technical decision: expand. The submitted line states the approach without showing the rule that makes layering useful. This page is the separate, detailed version: it shows each layer's responsibility, the direction dependencies are allowed to travel, and the tests that enforce it.

Expanded answer

Yes. A typical solution is Api (controllers/endpoints, model binding, problem details, authentication — no business rules), Application (use cases, orchestration, validation, DTOs, the ports the use case needs), Domain (entities, value objects, aggregates, invariants, domain events — zero framework references) and Infrastructure (EF Core or ADO.NET, external services, messaging, storage, composition root). Dependencies point inward: Infrastructure implements interfaces declared by Application and Domain, never the reverse. Loose coupling comes from those ports; high cohesion comes from keeping a use case and the rules it protects together; separation of concerns is what makes the domain testable without a database, and the boundaries are checked by architecture tests in the build.

Layer	Owns	Must not
Api	transport, auth, validation at the edge, DTOs	contain business rules or query the database directly
Application	use cases, orchestration, ports, transactions	reference EF Core, HTTP or any outer implementation
Domain	invariants, aggregates, value objects, domain events	reference any framework or infrastructure package
Infrastructure	adapters: repositories, gateways, messaging, composition root	be depended upon by Domain or Application
Cross-cutting	logging, tracing, caching behind interfaces	leak framework types into the inner layers
Enforcement	architecture tests + boundary contracts	rely on convention alone, which erodes over time

Live layering workflow proof

The running component below changes its layer/result view through real event binding. Select a layer to see what it owns, the reasoning behind the boundary, and the evidence that the boundary holds.

LAYERING WORKFLOWRUNNING

Choose a layer or boundary rule

Select a step to inspect what it owns, the reasoning and the evidence.

$ Api → Application → Domain ← Infrastructure (dependencies point inward)

Four layers with a single dependency direction: the domain knows nothing about EF Core or HTTP, and infrastructure implements the interfaces the inner layers declare.

package references inside the domain project: 0
architecture test violations: 0

What the layering buys

Rules I apply. Let the domain own the rules and depend on nothing; declare ports in the inner layer and implement them outside; keep the composition root as the only place that names a concrete type; map entities to DTOs at the boundary so the database shape never becomes the API contract; and enforce all of it with architecture tests, because a boundary nobody checks is a boundary that disappears in the next sprint.

Boundary for Q26: this page covers layering and the dependency rule in .NET solutions. Module decomposition by bounded context, distributed deployment of those layers and team-ownership models are separate topics.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other three are the layers as they exist in the solution.

Acceptance criteria

Names the layers and what each one owns.
Keeps dependencies pointing inward, with ports declared by the inner layers.
Shows an interactive proof of choosing a layer and reading the evidence.
Keeps the domain free of framework references and the API contract free of entities.
Enforces the boundaries with tests, not with convention.