Например пользователь оформляет заявку на оплату счета. В моменте оформления эта заявка сохраняется в бд, ей ставится статус исполняется и кидается Event в сервис бухгалтерии.
В сервисе бухгалтерии принимается данный event, создается в бд заявка для бухгалтеров. Они там чего-то считают, инфу заносят, документы прикрепляют. После того, как заявка готова, бухгалтер переводит ее в статус готово и новый Event улетает обратно в сервис пользователя, где той заявке проставляется статус готово и прикрепляется документ из бухгалтерии во вложения.
То есть, у тебя есть два контекста (Пользовательский, бухгалетерский). В каждом контексте есть своя "Заявка" с разными полями, агрегатами и поведением. И жить эти контексты могут изолированно.
спасибо за мысль, не думал про конкурентность, когда писал эту часть. можно было притянуть что проверка уникальности тоже будет проводиться на сервисном уровне и что полноты модели не будет, но вот пример тогда с findAll действительно бессмысленный и даже вредный. Эту часть решил выпилить, чтобы не плодить ересь :)
Отмечу, что в данной статье акцент именно на бизнес процессах и основных стратегических паттернах. Это самая важная часть в DDD и в этой части код не нужен.
Совсем скоро напишу статью по тактическим паттернам и архитектуре, где кода и примеров будет много
Например пользователь оформляет заявку на оплату счета. В моменте оформления эта заявка сохраняется в бд, ей ставится статус исполняется и кидается Event в сервис бухгалтерии.
В сервисе бухгалтерии принимается данный event, создается в бд заявка для бухгалтеров. Они там чего-то считают, инфу заносят, документы прикрепляют. После того, как заявка готова, бухгалтер переводит ее в статус готово и новый Event улетает обратно в сервис пользователя, где той заявке проставляется статус готово и прикрепляется документ из бухгалтерии во вложения.
То есть, у тебя есть два контекста (Пользовательский, бухгалетерский). В каждом контексте есть своя "Заявка" с разными полями, агрегатами и поведением. И жить эти контексты могут изолированно.
Спасибо за интерес, дополнил в статье пункт про тестирование с типами
спасибо за мысль, не думал про конкурентность, когда писал эту часть. можно было притянуть что проверка уникальности тоже будет проводиться на сервисном уровне и что полноты модели не будет, но вот пример тогда с findAll действительно бессмысленный и даже вредный. Эту часть решил выпилить, чтобы не плодить ересь :)
Отмечу, что в данной статье акцент именно на бизнес процессах и основных стратегических паттернах. Это самая важная часть в DDD и в этой части код не нужен.
Совсем скоро напишу статью по тактическим паттернам и архитектуре, где кода и примеров будет много