Q27 proof · Architectural layers: API/Presentation, Application/Business, Domain, Infrastructure/Data Access

27. Architectural layers API / Application / Domain / Data Access

Answer as submitted

“Yes — that four-layer model (API/Presentation, Application/Business, Domain, Infrastructure/Data Access) is my default architecture on .NET, Spring Boot and FastAPI projects.”

Technical decision: expand. The submitted line names the layers without showing what each one owns or how a single request moves through them. This page is the separate, detailed version: it walks the four layers, traces one request across all of them, and shows the same pattern in the three stacks.

Expanded answer

Yes, on .NET, Spring Boot and FastAPI alike. API / Presentation handles transport only: routing, model binding, edge validation, authentication, RFC 7807 problem details and the wire contract, expressed as DTOs so no persistence entity ever escapes. Application / Business owns one use case per operation and declares the ports it needs — repository, unit of work, clock, event publisher — which keeps the technology choice outside the use case. Domain holds the entities, aggregates, value objects and invariants with no framework reference at all, so the rules are executable documentation. Infrastructure / Data Access implements those ports: EF Core, Spring Data JPA or SQLAlchemy, messaging, storage, outbound HTTP and the composition root. The dependency direction is always inward, each responsibility belongs to exactly one layer, and the boundaries are asserted by architecture tests rather than by convention.

Layer	Owns	Must not
API / Presentation	routing, model binding, edge validation, authn/authz, DTOs, problem details	hold business rules or open a database connection
Application / Business	one use case per operation, orchestration, transaction boundary, ports	reference an ORM, an HTTP client or infrastructure types
Domain	entities, aggregates, value objects, invariants, domain events	reference any framework, I/O or serialisation package
Infrastructure / Data Access	port implementations, ORM configuration, migrations, messaging, storage, composition root	be referenced by API, Application or Domain code
Contracts between layers	interfaces declared by the inner layer, DTOs at the boundary	let an entity shape the public API contract
Enforcement	architecture tests, project or package boundaries, review checklist	depend on discipline alone, which erodes under deadline

Live layer-flow workflow proof

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

LAYER FLOW WORKFLOWRUNNING

Choose a layer, a trace or the cross-stack mapping

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

$ API/Presentation → Application/Business → Domain ← Infrastructure/Data Access

The four layers in the order a request travels: transport at the edge, use cases in the middle, business rules at the core and the adapters that touch the outside world. Each responsibility belongs to exactly one layer.

layers: 4
responsibilities owned by exactly one layer: 4
layers that may be skipped: 0

What the layering buys

Rules I apply. Give every responsibility exactly one home so a change has one place to land; declare ports in the inner layer and implement them outside, so the technology is a decision made at the edge; keep the wire contract in its own DTO type so the schema never becomes the API; keep the domain free of framework references so its rules can be tested without a database or a container; and enforce the direction with architecture tests, because a boundary nobody checks is a boundary that disappears in the next sprint.

Boundary for Q27: this page covers the layer catalog, the flow of one request through the layers and the cross-stack equivalence. Module decomposition by bounded context, distributed deployment of the layers, event-driven choreography between them 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 others declare the layer catalog, the presentation layer in .NET, and the same four layers mapped across .NET, Spring Boot and FastAPI.

Acceptance criteria

Names all four layers and what each one owns.
Traces one request through every layer, in order, without skipping or repeating one.
Shows an interactive proof of choosing a layer, a trace or the cross-stack mapping and reading the evidence.
Keeps the dependency direction inward and the wire contract free of entities.
Shows the same separation in .NET, Spring Boot and FastAPI rather than a single stack.