Блог

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

Мой код вдохновлен этим репозиторием https://github.com/asadsahi/AspNetCoreSpa , где они используют функции, где каждая папка содержит все правила проверки и логику для конкретной функции внутри прикладного уровня.

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

И в чем причина того, что они перенесли всю бизнес-логику на уровень приложений, в то время как объекты домена не имеют никакой логики?

Я нашел хорошую статью, в которой рассказывается о том, что мне здесь нужно, о дублировании в обработчиках MediatR

Исключая подобработчики или делегирующие обработчики, куда должна идти моя логика? Теперь мне доступно несколько вариантов:

Собственный класс (с соответствующим именем) Служба домена (как и ее первоначальное назначение в книге DDD) Метод расширения базового класса обработчика Метод в моем методе DbContext в моем совокупном корне / сущности Что касается того, какой из них наиболее подходит, это, естественно, зависит от того, что на самом деле делает дублированный код. Общий запрос? Метод в DbContext или метод расширения для IQueryable или DbSet. Поведение домена? Метод в вашей модели домена или, возможно, в службе домена. Здесь много вариантов, это действительно зависит от того, что дублируется и где лежат эти дублирования. Если дублирование находится в папке функций, хорошей идеей будет базовый класс обработчика для этой папки функций.

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