Где я должен поместить логи запроса c, связанные с фильтрацией данных по роли пользователя в архитектуре DDD

Question

Я следую DDD архитектуре для моего приложения. У меня есть слой приложения, слой домена и слой доступа к данным (хранилище). Допустим, в моем приложении будет 3 роли: администратор, руководитель, агентство. Каждая роль должна иметь доступ к данным, которые ей назначены. Таким образом, проблема заключается в том, должен ли я поместить запрос logi c, чтобы отфильтровать данные по роли в репозитории, как

var query = dataContext.Order.Where(...);
if(userRole = "admin")
query =.... filter by admin
If(usrRole = "supervisor")
query =.... 
return query.ToList();

Я думаю, что logi c относится к бизнес-логикам c и должен быть вставлен в доменный слой. Но я не понимаю этого. Ребята, можете ли вы объяснить это для меня?

Answer 1

Репозитории представляют собой совокупности совокупных корней. Поэтому, когда вы хотите получить какой-либо агрегат или список агрегатов, которые вам необходимы для выполнения бизнес-операций в хранилище, вам нужно: go.

В вашем случае, я полагаю, у вас есть какой-то Пользователь агрегат, и я могу думать о таких методах, как следующие в вашем хранилище: findById (идентификатор пользователя) findByRole (роль UserRole)

Хотя findById () будет возвращать только один агрегат, а findByRole () возвращает список агрегатов.

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

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

Answer 2

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

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

Уровень приложений (содержащий службы приложений) предоставляет API вариантов использования и координирует запросы с соответствующими службами домена. Следовательно, код в службах приложений является процедурным, в то время как код в модели предметной области обычно намного богаче. То есть, если домен достаточно сложен, чтобы гарантировать это.

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

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

Для полноты DDD допускает множество архитектур, если у домена нет зависимостей. Хотя мне проще всего набрать asp, если подумать об этом