Layered Architecture

A typical enterprise application has four layers. The presentation layer handles interaction with the outside world, such as REST controllers, web pages and message listeners. The application layer coordinates use cases, such as placing an order, managing transactions and authorisation and calling the domain. The domain layer contains the business model and rules, such as orders, prices and invariants. The infrastructure layer provides technical capabilities such as persistence, messaging and calls to external systems. Each layer has a clear responsibility, so changes to, for example, the database or the API format stay mostly within one layer.

The presentation layer handles everything specific to how the application is called. For a REST API that means controllers, request and response DTOs, mapping between DTOs and application commands or results, validation of the input's shape with Bean Validation, content negotiation and mapping outcomes and exceptions to HTTP status codes and error bodies. Message listeners and scheduled jobs are also presentation-layer entry points. It should not contain business rules or call repositories directly. Keeping it thin means the same use cases can be offered through several channels, and the API can change without touching the domain.

The dependency rule says that a layer may depend only on layers below it, never on layers above. Presentation depends on application, application on domain, and so on, but the domain never calls a controller or knows about HTTP. In a stricter form, upper layers depend on abstractions that lower layers implement. The rule keeps the core of the system stable: changes in the user interface or in technical details do not ripple into business logic. It also prevents cycles between layers, which would make them impossible to change or test independently. Tools such as ArchUnit can enforce it automatically.

In classic layering, the domain sits above infrastructure and depends on it, for example on JPA repositories. Hexagonal architecture inverts that dependency. The domain and application core define ports, which are interfaces describing what they need, such as OrderRepository or PaymentGateway, and infrastructure adapters implement those ports with specific technologies. Inbound adapters, such as controllers, call the core through its use-case ports. The core therefore depends on nothing technical, can be tested without databases or web servers, and can switch technologies by replacing adapters. Layers still exist, but dependencies all point inward towards the domain.

A controller that calls a repository directly skips the application layer, where use-case logic lives. Transactions, authorisation checks, business validations and domain events are then either missing or reimplemented in the controller. When the same operation is later exposed through another entry point, such as a message listener or batch job, the rules must be duplicated, and they drift apart. Controllers also become harder to test and grow into large classes mixing HTTP and business logic. Routing every operation through an application service keeps rules in one place and makes the controller a thin translation layer.

Write the rules as automated tests that run in the build. ArchUnit's layeredArchitecture rule can declare the layers by package and state which layers may access which, so any violating import fails the build. Additional ArchUnit rules can forbid framework dependencies in the domain, for example no Spring or JPA annotations in domain packages. Spring Modulith can verify module boundaries and dependencies between application modules and generate documentation from them. Combine these with code review guidelines for new dependencies. Automated checks are essential, because layering erodes gradually through small shortcuts that each look harmless.

For anything beyond a small application, package by feature or module first, and use layers inside each module. A layer-first structure, with top-level packages for controllers, services and repositories, scatters each feature across the whole code base and makes module boundaries invisible. A feature-first structure, such as orders, payments and catalog packages, each containing its own web, application, domain and infrastructure sub-packages, keeps related code together, makes ownership clear and allows package-private visibility to hide internals. It also prepares the code for modularisation tools such as Spring Modulith, and for extracting a module into a separate service later.

Good layering makes a monolith much easier to split. If each module exposes its capabilities through an application-layer API, such as an OrderService interface, and its infrastructure dependencies are inverted behind ports, then extracting the module as a service mostly means replacing in-process calls with remote calls, such as REST or messaging, and moving the module's data to its own database. The domain code moves unchanged. Without layering, business logic is tangled with controllers and data access, so extraction requires a rewrite. That is why a well-layered, modular monolith is often the best first step towards microservices.