Как реализовать сервисы и репозитории на луковой архитектуре?

Question

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

1. Может ли модель (или сущность) ссылаться на интерфейс хранилища или интерфейс службы?

   Например: Order сущность имеет DeliveryCity отношения установлены через Oder.DeliveryZip свойство, которое не является внешним ключом, но является уникальным. Чтобы получить Город за молнию, я должен позвонить ICityRepository.FindByZip(zip)

   У меня есть следующий код в моей модели

   class Order
   { 
       . . .
   
       [Inject]
       public ICityRepository CityRepository { get; set; }
   
       private City _dCity;
   
       public City DeliveryCity {
           get {
               if (_dCity == null)
                   _dCity = this.CityRepository.FindByZip(this.DeliveryZip);
   
               return _dCity;
           }
       }
       . . .
   }
   

2. Каковы будут проблемы вышеуказанного кода? Должен ли он использовать службу домена вместо этого?

3. Должны ли реализации доменных служб быть определены внутри ядра или на уровне инфраструктуры?

Answer 1

Это где фабрики вписываются в домен. OrderFactory может принимать зависимости, такие как зависимость от IOrderRepository, а также зависимость от ICityRepository. Когда фабрика используется для создания (или восстановления) сущности Заказа, фабрика может искать Город и соответственно устанавливать свойство Заказа. Или, как предполагает Герцмейстер, установите его с помощью Lazy, чтобы поиск выполнялся только при необходимости.

Answer 2

Каковы будут проблемы вышеуказанного кода? Должен ли он использовать службу домена вместо этого?

Здесь нужно учитывать две вещи:

1. ICityRepository не является реальной зависимостью для Order, другими словами, Order не нуждается в этом для других своих методов. Реальная зависимость - это то, без чего объект не может работать. Таким образом, вы можете рассмотреть возможность передачи его в качестве параметра методу вроде 'GetDeliveryCity'(см. это для деталей).

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

Должны ли реализации доменных служб быть определены внутри ядра или на уровне инфраструктуры?

Внутри ядра, если это действительно доменная служба (не служба приложений).

Answer 3

1. Как насчет

   private Lazy<City> _dCityLazy;
   
   public City DeliveryCity {
       get {
           return _dCityLazy.Value;
       }
   }
   

   где вы будете вводить Lazy<City> по какому-то механизму?

2. В этом примере вы могли бы гибко принять решение путем инъекции извне.

3. Я бы сказал, что это действительно зависит от того, что делает конкретная доменная служба и где она используется.