Adem Catamak
2 min readJul 19, 2023

--

Hello Lukas,

This is a very good question :)

Domain layer is seen as the part where the abstraction process is done. For this reason, Repository interfaces are placed in this layer. Under the title of "Domain Layer", this situation is expressed with the following sentence: "In this layer; entities, value objects, aggregates, factories and interfaces will take place."

We can consider such an example to demonstrate the usefulness of putting interfaces in the domain layer.

First, let's consider an application that does "User Management". User object creation will be done by obtaining user name and password information. As a rule, the password should be stored after hashing. We can assume that this is a domain rule rather than an application rule. All these assumptions lead us to create a service/factory at the domain layer. Moreover, this service/factory depends on an interface like IHashService. At this point we have no choice but to put the IHashService interface in the domain layer. Then we can complete the IHashService implementation through 3rd party libraries in one of the other layers.

Similarly, let's imagine you want to write a rule to check that the username is unique before creating a user. This rule is a rule belonging to the domain layer. When you make the necessary development to put this rule in the domain layer, a piece of code similar to the one below will appear.

// Somewhere in Domain Layer

class UserNameShouldBeUnique

{

IUserRepo userREpo;

bool Check(string desiredUsername)

{

bool unique = !userRepo.DoesExist(desiredUsername);

...

}

}

The way to have the option to create such a piece of code is to store our interfaces in the Domain layer. If we consider putting the interface somewhere other than the Domain Layer, we cannot access the interfaces when we need to create a domain service.

I hope my explanation was clear and sufficient. Do not hesitate to contact me if you have questions.

--

--