RTS Questionnaire · Question 27 of 52 · file: answers/q27.html
Have you worked with architectural layers such as API/Presentation, Application/Business, Domain, and Infrastructure/Data Access?
ArchitectureLayersBackend
✅ Yes — that four-layer model (API/Presentation, Application/Business, Domain, Infrastructure/Data Access) is my default architecture on .NET, Spring Boot and FastAPI projects.
🧪 Interactive proof: this answer has its own page with a live layer-flow workflow, one request traced through all four layers, the cross-stack mapping and the acceptance criteria — open the Q27 architectural-layers proof →
Technical detail
- 🚪 API / Presentation — controllers or minimal endpoints, request/response DTOs, model validation, versioning, authentication/authorization filters, ProblemDetails-style error contracts, OpenAPI documentation and rate limiting. No business logic here.
- 🧭 Application / Business — use-case orchestration: command/query handlers or application services that coordinate domain objects, transactions, units of work, mapping and cross-cutting policies (caching, idempotency, events).
- 💎 Domain — entities, aggregates, value objects, domain services, specifications and business invariants, expressed in ubiquitous language and free of framework dependencies so the rules are readable by business stakeholders.
- 🔌 Infrastructure / Data Access — repositories, EF Core/Dapper or Spring Data implementations, messaging (Kafka/RabbitMQ/Service Bus), file/object storage, external HTTP clients, caching and migrations, all registered behind interfaces through dependency injection.
🧩 Extras I apply: strict dependency direction (outer depends on inner), composition root at startup, mapper layer between DTOs and domain objects, and architecture tests that fail the build if a forbidden reference appears. 🔁 The same structure maps cleanly to hexagonal/ports-and-adapters, which makes the system testable and lets infrastructure change without touching business rules.