Сервисы и авторизация в луковой архитектуре

Я пытаюсь изучить Onion Architecture и, насколько я понимаю, я организовал свое решение следующим образом:

Домен

  • Domain.Entities (бизнес-объекты)
  • Domain.Interfaces (Интерфейсы для доменных служб и репозиториев)
  • Domain.Services (Реализация для интерфейсов доменных служб)

Инфраструктура

  • Infrastructure.Data (реализация для репозиториев и единицы работы с EF)
  • Infrastructure.DependencyResolution (реализация для IoC с Unity)

UI

  • UI.WebMVC

И вот мои вопросы:

1- Я прав с этими слоями или что-то упустил?

2- Что касается услуг, связанных с определенной технологией (например, ведение журнала), где должны быть их интерфейсы (Domain.Interfaces или Infrastructure.Interfaces)?

3- Насколько я понимаю, Служба домена обработает мой бизнес-вариант использования, так каковы преимущества, которые я получу от службы приложений

4- В чем разница между доменной службой и службой приложений и в каком проекте должны быть интерфейсы службы приложений?

5- Должен ли процесс авторизации пользователя быть частью служб приложений или доменных служб?


domain-driven-design onion-architecture
person Mahdy    schedule 15.09.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

введите описание изображения здесь

  1. Это схема гексагональной архитектуры, но она очень близка к луку и ИМО, вы должны ее использовать. Здесь показаны 3 уровня: домен (желтый), приложение (красный), инфраструктура (зеленый + синий). Итак, отвечая на ваш вопрос - вам не хватает нескольких элементов, таких как службы приложений.

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

  3. Доменные службы заботятся только о вещах, связанных с вашим бизнесом. Прикладные службы большую часть времени готовят почву для доменных служб, например, создают репозитории и получают из них агрегаты, затем вызывают доменные службы и передают туда эти агрегаты. Вы не должны обрабатывать свою бизнес-логику на уровне приложения!

  4. Как я писал в пункте 3. Прикладные службы должны быть в каждом проекте, использующем доменные службы.

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

person Rafał Łużyński    schedule 15.09.2014
comment
Спасибо за ваш ответ Рафаль, я сейчас в замешательстве. 1- Должны ли службы приложений быть в отдельном проекте (dll) или в каждом проекте, который использует доменные службы в решении? 2- В вашем примере о службах приложений вы сказали, что они создают репозитории и извлекают из них агрегаты для передачи в службу домена. Почему я делаю это в службе приложений, когда у меня есть полный доступ к репозиториям из службы домена? - person Mahdy; 16.09.2014
comment
1. Службы приложений обрабатывают службы домена, вы не должны обрабатывать службу домена напрямую из инфраструктуры (например, из контроллера / представления инфраструктуры). 2. Потому что на уровне домена вы выполняете только бизнес-логику. Получение агрегатов - это не бизнес-логика. Вам следует изучить DDD Эванса или, по крайней мере, IDDD Вернона. - person Rafał Łużyński; 16.09.2014
comment
Спасибо, Рафал, я думаю, мне все становится яснее. - person Mahdy; 17.09.2014