Comments 9
Вопрос по примеру из раздела Transaction Script, если возникнет необходимость написать утилиту командной строки с авторизацией, будете использовать эти же скрипты?
Как выглядят тесты для проверки этих скриптов? К какому типу тестов они относятся?
Если у пользователя есть личный кабинет, в котором он может запросить счет на оплату. В своем кабинете пользователь видит свой запрос счета и может его отменить. Этот запрос должен попасть в личный кабинет бухгалтерии, они должны его обработать и результатом должно стать появление счета в кабинете клиента. Кто разбирается в DDD и не лень, можете описать кому в данном случае что принадлежит (например "запрос счета" принадлежит пользователю или бухгалтерии? А выставленный счет кому принадлежит?) И каким образом происходит взаимодействие (например, как запрос счета появляется в бухгалтерии после того как пользователь нажал на кнопку?).
Например пользователь оформляет заявку на оплату счета. В моменте оформления эта заявка сохраняется в бд, ей ставится статус исполняется и кидается Event в сервис бухгалтерии.
В сервисе бухгалтерии принимается данный event, создается в бд заявка для бухгалтеров. Они там чего-то считают, инфу заносят, документы прикрепляют. После того, как заявка готова, бухгалтер переводит ее в статус готово и новый Event улетает обратно в сервис пользователя, где той заявке проставляется статус готово и прикрепляется документ из бухгалтерии во вложения.
То есть, у тебя есть два контекста (Пользовательский, бухгалетерский). В каждом контексте есть своя "Заявка" с разными полями, агрегатами и поведением. И жить эти контексты могут изолированно.
Отличная статья чтобы освежить знания в выходные.
Примеры со сменой email-адреса некорректны, поскольку между выборкой и сохранением есть момент когда может произойти вставка данных из другого потока, проверка не сработает и получим двух пользователей с одинаковым email. Можно использовать pessimistic locking, но тогда это приведет к снижению производительности системы. Самый разумный вариант это уникальный индекс в хранилище данных по email, никаких проверок, меняем email и сохраняемся. Также обычно такие штуки
await this.repository.findAll()возвращают не данные, а курсор по которому можно итерироваться и никаких утечек по памяти не будет.
Вообще про трилемму это явно взято из блога Владимира Хорикова. У автора есть неплохие статьи, но эта точно не из их числа.
спасибо за мысль, не думал про конкурентность, когда писал эту часть. можно было притянуть что проверка уникальности тоже будет проводиться на сервисном уровне и что полноты модели не будет, но вот пример тогда с findAll действительно бессмысленный и даже вредный. Эту часть решил выпилить, чтобы не плодить ересь :)
Методология DDD возникла в значительной мере для решения проблемы отделения доменной логики от функционала, который взаимодействует с базой данных. Поэтому не совсем понятно наличие паттернов Transaction Script и Active Record среди паттернов DDD. Эти паттерны всегда связаны с механизмами взаимодействия с базами данных.
Тактические паттерны DDD