DDD - Business decisions are based on database logic

Question

I am trying to follow DDD in the following pattern.

Controller-----DataContract----> Domain Layer (DDD)

Controller-----Domain Object---> Repository---Entity--->EntityFramework

As you see in the above diagram, the domain layer is independent to make business decisions, but in my case, most of the business decisions are taken on the fly. For example,

if(Account Number Associated?)
     Load CustomerDetails //A database call is needed
     ....
     .....
     if(Has customer another loan)
           .....
           .....
           Load other loan details //A database call is needed
           .....
           .....
           if(Was that repaid?)
               ....
               ....
               Load collateral details //A database call is needed
               .....
               .....
               Calculate collateral details and return.
           else
               Load other data //A database call is needed
      else
           Load other data //A database call is needed

else
     Load other data //A database call is needed

As you see the above example, the application is making a lot of business decisions on the fly by making database calls. Since Domain Layer should not depend on the Repository Layer, I don't know how to proceed.

I may use Application service for database calls, but then Domain Layer wouldn't have any logic in it. All the logic would go into the Application Service.

Please help me in this.

-Pandian

Answer 1

There are at least three possible ways out

1) Design your repository to load the entire aggregate at once. This approach gives the domain model all of the state that it may need right away, rather than trying to load the state on demand.

2) Run the queries in the app service, and pass the data to the domain model. Ideally, you do this in advance (so that you are making a single call into the domain model), but when that doesn't make sense you have the domain model tell the app service what data is needed, and the app service finds that data and returns it.

3) Pass a repository into the domain model that allows it to read the data that it needs. This is essentially the "domain service" pattern, but used to access a data store.

In this design, the domain model is defining the repository interface, and the application provides the implementation. In other words, we're using the service provider pattern to keep the dependency arrows pointing the correct direction.