# Domain Layer Separation

**In short:** Domain layer separation keeps business logic in its own layer, apart from the user interface, the application layer, and technical infrastructure. Several front ends can then reuse the same logic.

## Explanation

Domain layer separation puts business logic into a layer of its own. The domain layer is the heart of a bounded context (see Bounded Context). It should be well isolated from the other layers. This isolation is central to Domain-Driven Design (see Domain-Driven Design).

**The layers around it**

- The presentation layer shows information to users and takes their input.
- The application layer, also called the service layer, stays thin. The key logic lies in the domain layer, not here.
- The infrastructure layer acts as a supporting library for the other layers.

**Logical, not physical**

These layers are logical layers, not physical tiers. You can split the code into layers without putting each layer on its own server.

**Direction of dependency**

Each layer should depend only on the layer below it.

**Why it pays off**

Separating presentation from domain logic lets you build several presentations on top of the same domain logic. You do not have to copy that logic into each one.

For the general idea of layers, see Layered Architecture.

## Example

An insurance company has a web portal and a mobile app. Both need the same rule for calculating a premium. The team keeps that rule in the domain layer. Both front ends reach it through a thin application layer. When the rule changes, the team edits one place. Neither front end holds its own copy.

## Trade-offs

The verified facts describe benefits, not costs. One caution follows from them: the application layer must stay thin. If key logic moves into it, the domain layer stops being the home of the business rules. Also remember that layers are logical. Drawing layers on a diagram does not by itself decide how the system is deployed.

Logical layers: the application layer stays thin and the domain layer holds the key logic.

```mermaid
flowchart TD
  UI[Presentation layer] --> APP[Application layer - thin]
  APP --> DOM[Domain layer - business logic]
  APP --> INF[Infrastructure layer]
  DOM --> INF
```

## Checks

- The domain layer is described as isolated from the other layers.
- The application layer is thin and the key logic sits in the domain layer.
- Each layer depends only on the layer below it.
- Layers are described as logical layers, not as physical tiers.

## Related

- [Layered Architecture](https://arc.fuet.ch/concepts/styles-patterns/layered-architecture.md)
- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- [Layers Pattern](https://arc.fuet.ch/concepts/styles-patterns/layers-pattern.md)
- [Clean Architecture](https://arc.fuet.ch/concepts/styles-patterns/clean-architecture.md)
- [Model-View-Controller Pattern](https://arc.fuet.ch/concepts/styles-patterns/model-view-controller-pattern.md)

## Sources

- [Presentation Domain Data Layering](https://martinfowler.com/bliki/PresentationDomainDataLayering.html) — martinfowler.com, accessed 2026-11-09
- [DDD.4 – Isolating the domain – @hgraca](https://herbertograca.com/2015/09/18/domain-driven-design-by-eric-evans-chap-4-isolationg-the-domain/) — herbertograca.com, accessed 2026-11-09
- [Anemic Domain Model](https://martinfowler.com/bliki/AnemicDomainModel.html) — martinfowler.com, accessed 2026-11-09
- [AgileDev - Layered Architecture](https://uniknow.github.io/AgileDev/site/0.1.10-SNAPSHOT/ddd/layered_architecture.html) — uniknow.github.io, accessed 2026-11-09