Layers in Domain Driven Design

Question

In Domain-Driven Design, the domain layer is said to have no dependency on other layers, i.e. the repository interface is within the domain layer, while its implementation is at the infrastructure layer.

However, the bounded context (with domain + infra) is deployed as one unit (deployable) so the layers are actually logical and not physical. Then what is the advantage of drawing this virtual separator between domain and infrastructure layers?

Update

In a traditional layered approach, the domain (service) is said to be dependent on the infrastructure layer. Conversely, when it comes to DDD / Clean / Hexagonal architectures the domain is independent of other layers because the domain layer has an interface that is implemented by the infrastructure layer.

Whether you use DDD or a traditional layered approach, you still have to mock repositories, meaning the domain is not actually independent. Is this correct?

Answer 1

The biggest driver is to allow the different layers to change without affecting each other. For example, I often test my domain layer independently of my infrastructure layer. I do this by mocking out my DAOs and Repositories, this allows my tests to run much faster, and makes them far less brittle.

I've also used it when my repository ends up needing a new implementation (Oracle vs MS SQL vs Web Service). It massively reduces your complexity when you don't have to rewrite your entire application when a back-end service changes out from under you.

Finally, splitting this tends to help you accomplish SRP. Integrating your database layer into your domain layer tends to allow you to skip this (at least in my experience). It doesn't force you to, but it certainly encourages bad behaviors.

It's the same reason we don't write our domain logic in our UI. For any sufficiently small example, it's a waste of time. It's value only becomes apparent when you have a large, complex application.