DDD - бизнес-решения основаны на логике базы данных

Question

Я пытаюсь выполнить DDD в следующем шаблоне.

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

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

Как вы видите на рисунке выше, домен слой независима для принятия бизнес-решений, но в моем случае, большинство деловых решений принимаются на лету. Например,

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 

Как вы видите, в приведенном выше примере, приложение делает много бизнес-решений на лету путем обращения к базе данных. Начиная с Уровень домена не должен зависеть от уровня хранилища , я не знаю, как действовать.

Я могу использовать службу Application для вызовов базы данных, но затем Layer домена не будет иметь никакой логики в нем. Вся логика войдет в прикладную службу .

Пожалуйста, помогите мне в этом.

-Pandian

Answer 1

Есть по крайней мере три возможных пути выхода

1) Дизайн репозиторий для загрузки всей совокупности сразу. Этот подход дает модели домена все состояние, которое может потребоваться сразу, вместо того, чтобы пытаться загрузить состояние по требованию.

2) Запустите запросы в службе приложений и передайте данные в модель домена. В идеале вы делаете это заранее (чтобы вы делали один вызов в модели домена), но если это не имеет смысла, у вас есть модель домена, сообщите службе приложения, какие данные необходимы, и служба приложения обнаруживает, что данных и возвращает его.

3) Передайте репозиторий в модель домена, которая позволяет ему считывать необходимые данные. Это по существу шаблон «службы домена», но используется для доступа к хранилищу данных.

В этом дизайне модель домена определяет интерфейс репозитория, и приложение обеспечивает реализацию. Другими словами, мы используем шаблон поставщика услуг, чтобы стрелки зависимости указывали правильное направление.

Answer 2

@Pandiarajan Доменный уровень может содержать модели домена (объекты, объекты значений), службы домена и события домена.

Из вашего кода выше вы можете создать службу домена, которая инкапсулирует всю эту логику и концепции домена, которые, естественно, не моделируются как объекты или объекты значений. Эти службы домена могут принимать репозиторий, который обрабатывает все вызовы базы данных.

Обратите также внимание, что если данные, которые необходимо вернуть, предназначены только для чтения или для целей отчетности, вы можете захотеть найти CQRS в качестве альтернативы. В CQRS все эти запросы на чтение могут обходить ваш доменный уровень при представлении данных. CQRS устранит необходимость преобразования ваших данных в модель домена.