Подходит ли шаблон WorkerService для создания ядра приложения в решении DDD?

Question

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

(Изображение вырезано из этого блога .)

Мне кажется, что это так, и это был бы более разумный выбор, чем использование веб-службы по умолчанию, как это делалось ранее.К сожалению, так как эта функция является новой в .NET Core 3, не так много надежного материала для поиска через Google.

Как я понимаю, я мог бы внедрить экземпляр класса наследования в DbContext врабочий, не влияя на архитектуру DDD тоже.Или есть соображение, что я здесь не вижу?

Answer 1

Начнем с того, что Domain-Driven Design никогда не был архитектурным стилем или образцом.Это подход к проектированию систем вокруг бизнес-доменов и идентификации различных уровней границ, таких как системные и лингвистические границы (ограниченный контекст) и транзакционные границы (совокупность).

Ядро большинства приложений, созданных с использованием DDDИмеется в виду модель предметной области.Модель предметной области - это старая модель, существовавшая задолго до DDD.Сам шаблон и его интерпретация DDD имеют одну важную характеристику - код, реализующий модель предметной области, не зависит от какой-либо инфраструктуры.Следовательно, он очень хорошо подходит для портов и адаптеров / гексагональной архитектуры.

Где именно размещена модель домена и какой тип прикладных служб (порты) и пограничный уровень (адаптеры), которые вы хотите иметь, полностью ортогональныв DDD.Служба работника, постоянный субъект, получатель сообщения, конечная точка REST или gRPC - что бы то ни было на самом деле.

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