Injection Dependencies Layers Application / Domain / Repository

Question

In an application using the DDD concepts I am in doubt about who could inject (dependencies) into the constructor of a given class if there is any standard for it.

For example, between the Application, Domain, and Repository layers.

1) A ClientAppService (Application layer) that needs to inject user, should I inject UserApplicationService and from it call UserService (Domain) or inject UserService directly in ClientApplicationService?

2) In the ClientService (domain) should I inject UserService and from it call UserRepository or could I inject UserRepository directly into ClientService?

I'm concerned about cyclic reference if I'm injecting peer classes.

But I also think that I should not inject the Repository of another Entity, because often the methods of the repository have a rule in the service that must be called previously.

Has anyone ever had this question, how do you usually handle it?

Answer 1

Thinking about separation of concerns and allocation of responsibilities, you should inject exactly what your artifact depends upon. This may sound a little obvious, but it goes a little deeper.

Considering your (2) example:

In the ClientService (domain) should I inject UserService and from it call UserRepository or could I inject UserRepository directly into ClientService?

You probably should first ask yourself which capability does your ClientService depend upon?

• If it (ClientService) cares about being able to find user from information it (ClientService) currently possesses, it should probably receive the UserRepository directly and be able to find the user on its own.

• If it (ClientService) needs a user, but it doesn't possess the information needed to find the user (this information is currently on application layer level), maybe ClientService should receive the User domain object directly, with the repository being used straight from application level.

• If it (ClientService) needs some kind of domain-relevant functionality from UserService as part of its operation, then, in that case, the UserService might be directly injected into ClientService.

Other possible discussion on this topic might whether you really need all those Domain Services of if you would be better calling rule-rich Entities/Aggregates straight from the Application Layer, it might make your overall design, injection patterns and boundaries simpler.

Also, many times, you might want to inject factories for your artifact rather than the instantiated ones directly.

Another point might be made about:

But I also think that I should not inject the Repository of another Entity, because often the methods of the repository have a rule in the service that must be called previously.

This might be evidence of some confusion inside your domain. The role of a repository should be around the lines of "finding your domain entity from the universe of possible entities". In that sense, a UserRepository enables you to find users from the users existing in your universe so it should be a pretty isolated operation and shouldn't depend on services or other entities. If a user exists, it should be "findable" (and persistable, as it goes both ways) from the UserRepository.

In that case, you shouldn't worry about "injecting UserRepository in ClientService" from a dogmatic point of view. If the operation in your client service needs to find and use a User Entity, it should be alright for you to do so. What you might worry about is whether your entities/aggregates are well designed or if you have some kind of misplaced responsibilities that might be triggering this "feeling" of "I shouldn't be injecting this into that".

Answer 2

Domain Entities and Value Objects almost never use constructor injection.

This is motivated by separation of concerns; the responsibility of the objects in the domain model is to manage their own in memory representations.

Other capabilities that they may need to do their work are passed to them as arguments.

The typical mechanism for this is the "domain service", described by Evans in chapter 5 of the blue book.

To sketch an example - suppose my order aggregate needs to update its quote when the line items change. I might pass in as an argument an interface that accepts a SKU and returns a Price. As far as Order is concerned, that lookup is happening "somewhere else". It doesn't care about the details. The implementation might load up another aggregate to look up its current state, or send a message to some remote system, or hard code an answer.

Domain Service implementations will often have injected dependencies on capabilities provided by the application or infrastructure layers.