mtsepkov

#MergeConf Денис Цветцих из T-Bank. Эффективные DomainEvents из DDD. Денис начал с того, что механизм Domain Events - полезен, но в литературе упоминается вскользь и противоречиво: автор одновременно пишет, что событие локально принадлежит ограниченному контексту и тут же указывает, что события используются для связи контекстов. То же касается транзакций - пишут, что этот механизм аналогичен триггерам БД и обеспечивает консистентность, и тут же упоминают про асинхронную отправку через сообщения. И дальше Денис подробно рассказывает о шаблонах применения событий.

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

В основе - c4 model. В ней бизнес - это вообще контекст исполнения. А дальше есть уровни: контейнеры - компоненты - код. И все бизнес-содержание в этой модели опущено на уровне кода, DDD применяется именно там, и Domain Events - этого уровня. А для интеграции используются DTO и Application Events, они очищены от доменной специфики.

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

И если подразумевать этот шаблон приложения, то примеры из доклада, как применять события вместо явного вызова команд, становятся понятными. Domain Events требует инфраструктуры - записи событий и их обработки. Отрабатывать можно перед commit на механизмах ORM. B создавать события их можно не только явно в коде, но и на механизмах ORM. Шаблонов и примеров было много, с кодом, так что пересказывать их сложно. Но можно посмотреть презентацию.

www.group-telegram.com/jp/mtsepkov.com/889

641 viewsMaxim Tsepkov, Nov 15, 2024 at 13:15

#MergeConf Денис Цветцих из T-Bank. Эффективные DomainEvents из DDD. Денис начал с того, что механизм Domain Events - полезен, но в литературе упоминается вскользь и противоречиво: автор одновременно пишет, что событие локально принадлежит ограниченному контексту и тут же указывает, что события используются для связи контекстов. То же касается транзакций - пишут, что этот механизм аналогичен триггерам БД и обеспечивает консистентность, и тут же упоминают про асинхронную отправку через сообщения. И дальше Денис подробно рассказывает о шаблонах применения событий.

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

В основе - c4 model. В ней бизнес - это вообще контекст исполнения. А дальше есть уровни: контейнеры - компоненты - код. И все бизнес-содержание в этой модели опущено на уровне кода, DDD применяется именно там, и Domain Events - этого уровня. А для интеграции используются DTO и Application Events, они очищены от доменной специфики.

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

И если подразумевать этот шаблон приложения, то примеры из доклада, как применять события вместо явного вызова команд, становятся понятными. Domain Events требует инфраструктуры - записи событий и их обработки. Отрабатывать можно перед commit на механизмах ORM. B создавать события их можно не только явно в коде, но и на механизмах ORM. Шаблонов и примеров было много, с кодом, так что пересказывать их сложно. Но можно посмотреть презентацию.

BY mtsepkov