В каком проекте должны жить модели чтения (проекции) в DDD с Event Sourcing?

Question

В типичной архитектуре DDD у нас есть 3 проекта:

Домен - нет ссылок

Приложение - имеет ссылку на проект домена

Инфраструктура - ссылка на проект домена

(+ проект Web / UI)

Модели домена, конечно же, живут в проекте домена Но в каком проекте должны жить модели чтения (проекции) для базы данных чтения, например MongoDb?

Answer 1

Если честно, это не имеет значения.Нет структуры по умолчанию ни для DDD-ориентированной, ни для реализации событий-ориентированной реализации.

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

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

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

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

Answer 2

Короткий ответ, как службы приложений (уровень приложений), так и репозитории (уровень инфраструктуры) знают о моделях READ. Уровень домена остается прозрачным для основных механизмов сохранения и загрузки.

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

Первый случай: использование моделей чтения в качестве объектов в слое домена

Служба приложений загружает модель READ из хранилища в объект домена. Ответственность за правильное заполнение модели READ в объекте домена лежит на хранилище. Хранилище также отвечает за преобразование сущности домена в модель WRITE для сохранения в первичной базе данных.

К тому времени, как вы перейдете к модели Домена, объекты уже загружены в память с помощью репозиториев. Таким образом, уровень домена даже не знает о модели READ и модели WRITE; это касается только сущности домена.

Второй случай: использование моделей чтения для хранения предварительно созданных ответов на запросы API

Этот сценарий является более типичным использованием моделей READ. Обычно для одной и той же сущности / агрегата существует несколько моделей чтения, поскольку они специально созданы для конкретных запросов API.

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