I have read Eric Evans book. I was under the impression that a Domain Model should not have dependencies injected (even repositories).
This statement is supported by questions like this: https://stackoverflow.com/questions/20035810/should-domain-objects-have-dependencies-injected-into-them, where the answerer says that "Domain Objects shouldn't depend on anything else". However, I then see this: http://www.zankavtaskin.com/2013/11/applied-domain-driven-design-ddd-part-4.html i.e. a domain service in the domain model that depends on the repository.
Should a Domain service have dependencies? I realise that application services have repositories injected.
2) The domain model (domain service?) goes to the database and gets details of the offers and returns them to the application service as a list of DTOs.
I was under the impression that a Domain Model should not have dependencies injected (even repositories).
Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance's individual history. The execution of a service will use information that is accessible globally, and may even change global information (that is, it may have side effects).
The domain service (facade) would have a dependency on the external service.
That said; looking back 10 years later, I'm not sure that he got the details of this one right. When you interact with state that is distributed somewhere else, that somewhere else may not be available. Distributed communication fails, and if that's not part of your domain, the logic for handling those failures starts to get in the way.
Gary Bernhardt and Cory Benfield both have given very interesting talks about separating side effect concerns from those of the model.
A model that transforms inputs into outputs is simple to reason about; a model that transforms inputs into outputs plus side effects, that's not simple any more.
The write/command part, where you do the modifications to your persisted objects. Here live the Aggregates and all they need to do their job, i.e. all their Value objects. This is referenced in the literature as "the domain model".
The read/query side where you show the persisted objects or some projection of them. Here stay the domain services and the Repository interfaces.
There are also the Sagas/Process managers that bridge the two parts.
Yes, I agree. This refers to the Write part of your application (i.e. the Aggregates).
Not the domain model but a domain service. This is strictly a read side concern (if you use this information to display it to the user or in a Saga).
The domain service and not the model, as I wrote in the previous paragraph. This really depends on how much you want to optimize the speed of the persistence retrieval as you can make use of the persistence optimisation and not fetch the entire documents/rows but only the data needed. Being on the read side you are "permitted" to do all kinds of optimisations.
In any case, the logic about the selection of those offers should stay in the domain layer.
P.s. there is the CQRS architecture/pattern that is based on this separation of read and write.
If the domain service is an intermediary between Customers and Offers, like a func returning the eligible offers, maybe the application service would use the domain service to select from the repository?
The interface for the repository can/should live in the Domain layer, so the implementation for the repository could be injected into the domain service.
A domain model and let's extend that to any model in general, should not have injectable dependencies.
A domain service (factory) is built inside the domain and is going to have constructor injection in any non-trivial software implementation. The minimum to inject typically is the infrastructure service (EF, Dapper, ADO? (your DTO's typically live here). The maximum? Anything and everything the domain has access to (facades, stand alone projects, other factories / domain services, etc...).
You can then throw an interface on the factory, wire it up in DI, and inject it that way abstracting out it's (many?) dependencies, until you have an intricate web of inter-dependencies that you'll find in most enterprise architecture.
Is Domain Driven Design useful / productive for not so complex domains?
How do you define a responsbility?
Should a Rich Domain Model have repositories injected in some situations?
DDD - Is anemic domain model an antipattern? Shoud we be using rich domain models?