Как организовать зависимости, реализующие CQRS и DDD

Question

Я пытаюсь внедрить услугу DDD с использованием подхода CQRS.Я не использую источник событий.Итак, у меня есть 3 уровня: приложение, инфраструктура и домен.Многие люди говорили, что вы можете обойти домен для запросов, и это нормально.Например, представьте, что это необходимо для меня из-за проблем с производительностью.

После постоянного невежества у меня есть реализация репозитория в инфраструктуре.Как я вижу во всех реализациях DDD и книг, инфраструктура не должна зависеть от прикладного уровня.

Так что мне нужно возвращать из репозитория ??Если DTO (чтение моделей, просмотр моделей - это не имеет значения) является проблемой приложения.Размещение их на уровне инфраструктуры создает круговую зависимость от приложения к инфраструктуре и наоборот.Но реализация логики запросов (если я использую Orm, который запрашивает посредством написания необработанного SQL) - плохой подход, потому что для этой цели мы создали хранилище в инфраструктуре (это был способ https://github.com/dotnet-architecture/eShopOnContainers).

. Другой подход - загрузкасобирает данные из репозитория, а затем конвертирует их в DTO, но это невозможно из-за моих вымышленных проблем. Так как с этим справиться правильно? (Это был способ https://github.com/JasonGT/NorthwindTraders/)

Answer 1

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

Что происходитпо кешу пропустить?Затем вам нужно поискать данные и вычислить, какими должны быть возвращенные байты.

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

Например, представьте веб-API, в котором клиент передает вам целевой URI и ожидает ответа application/json.Хранилище данных с состоянием - это некая СУБД, поэтому вы используете готовый SQL-клиент для выполнения запроса, который выдает ResultSet.Затем вы бы использовали что-то вроде DOM-компоновщика для построения дерева, перебирая строки в наборе результатов и копируя столбцы данных в дерево.Когда дерево будет готово, вы будете использовать библиотеку json для добавления представления дерева в UTF-8.Тада, у тебя есть представление ответа, который ты можешь вставить в кеш и вернуть клиенту.

Если тебе удобнее с O / RM, то ты можешь определить представление объекта в памяти,и пусть O / RM беспокоится о создании в памяти представления результата, которое вы затем передаете в библиотеку десериализации JSON.

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

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

Answer 2

Если вы хотите следовать «Чистой архитектуре» Роберта С. Мартина, вы должны отделить стабильные бизнес-правила (абстракции более высокого уровня) от изменчивых технических деталей (детали более низкого уровня), определяя четкие границы.Ваши зависимости исходного кода должны указывать только внутрь, на политики более высокого уровня.Чтобы достичь этого, используйте принцип инверсии зависимости.Определите интерфейсы для хранилищ в слое, где они вам нужны.Затем реализуйте эти репозитории на уровне инфраструктуры.

Это означает, что прикладной уровень не должен зависеть от уровня инфраструктуры.Но уровень инфраструктуры может зависеть от уровня приложения (инфраструктура может использовать приложение).