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

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. Когда фабрика используется для создания (или воссоздания) объекта Ордера, фабрика может искать город и соответственно устанавливать свойство Order. Или, как предполагает herzmeister, установите его с помощью Lazy, чтобы поиск выполнялся только при необходимости.

Answer 2

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

Две вещи, чтобы рассмотреть здесь:

1. ICityRepository не реальная зависимость для заказа, другими словами заказа не нужно для ее другими методами. Реальная зависимость - это то, с чем объект не может работать без. Поэтому вы можете рассмотреть возможность передачи его в качестве параметра к методу типа «GetDeliveryCity» (см. this).

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

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

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

Answer 3

1. Как насчет

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

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

2. Вы бы выбрали гибко путем инъекции снаружи, а затем в этом примере.

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