I'm a seasoned programmer but a novice with DDD. I have a project that I'm trying to implement with DDD and my understanding is that there is some ambiguity with regard to the use of domain models and application services. In the purest of DDD implementations, my understanding is that domain models are supposed to contain all business logic. However, this doesn't seem like a realistic goal to me. In simple validation scenarios and such, this is all well and good, but the goal of encapsulating business logic in domain models gets a little slippery when we think about logic requiring additional services such as database lookups/persistence and other external dependencies.
For example, I have a domain model "Order" that has a method "IsValid". To determine whether an order is valid, a database read must be performed. In order to keep the model clean, I don't want to inject any database work into it. OK fine - I create an OrderService to do the database hit and pass in a result to "IsValid" so that the dependency on the database resides with the service. However, what happens if there are multiple database hits that depend on business logic? Is it appropriate to add that logic to the application service? If so, it seems that business logic is leaking into the application services layer which is a violation of DDD. However, if we move the logic inside the domain model and do the database hit there, we're mixing concerns and also violating DDD.
Can anyone experienced with DDD provide any insight into how to deal with this sort of an issue? DDD seems like it provides a lot of nice value, but I'm worried about these kinds of issues leading to design "rot".
JOIN
queries to perform an eager fetch of related entities, which should mitigate the N+1 query problems.select
's they are doing could probably be accomplished by tweaking the mappings.