ArchDays 2020 • Агрегаты, мои агрегаты, как приятно о вас думать! • Евгений Пешков (Dodo Eng)

[@SntrTube]

Начало по существу 4:44 Пример кода анимичной модели 7:17 Антипатрн универсальная модель 11:32 Все плохо! Что же делать? 18:27 Примеры кода анимичной модели 19:54 Пример кода как можно отрефакторить 27:54 О cohesion и coupling 34:35 Закон диметры 37:40 Intro про агрегаты 41:45 Про Entity и что такое Identity 43:49 ValueObject 45:51 Про агрегаты по существу 47:09 Про инварианты 52:16 Важность сохранения агрегата одной транзакцией 56:56 Вопрос : Может ли агрегат содержать другие агрегаты? И как с этой зависимостью быть? 1:04:56 Границы агрегата 1:07:49 DDD трилема 1:12:00 Про консистентность 1:15:59 Transactional outbox pattern1:16:50 Поход Optimistic consistency 1:21:17 Поход Optimistic cuncarancy 1:22:28 Вопрос про Transactional outbox pattern 1:23:11 Про Хранение агрегата 1:25:24 Про Event sourcing 1:27:10 Пример кода Event sourcing 1:29:50 Дискуссия 1:40:20

[@andrewtsvetsih2675]

Евгений, спасибо за доклад! Было интересно, вы затронули много вопросов. По каждому из них можно сделать отдельный доклад :) Этот доклад получился обзорным и в меньшей степени практичным. Есть предложение для след. докладов - взять какой-то один вопрос и показать подробнее. И на примере, который ближе к реальности (например, когда в сущности больше полей). Например анемичные и универсальные модели - покажите как вы одну универсальную модель заказа разделили на две: для кухни и для курьера. Это будет очень интересно и более практично. По DDD много обзорных материалов, но почти подробностей и реального опыта. А этот реальный опыт и есть самое ценное и интересное на подобных выступлениях. Если вы расскажете "как мы в додо делаем вот это" - это будет очень круто! Теперь вопросы про event sourcing: - вы его использовали с самого начала или потом на него перешли? - сейчас этот подход используется везде или нет? Например у наc всю используется CQRS а event sourcing не используется совсем. Поэтому основной вопрос не в том "как" а в том "когда" использовать event sourcing.

[@Olga-pc3bm]

Правильные технические переводы терминов: low coupling - слабые внешние связи, слабая внешняя зависимость, high cohesion - высокая внутренняя связанность

[@VitalyBelenky]

Толково, спасибо!

[@vitek0585]

Хороший доклад от Жени, если есть возможность расшарить ссылки на презентацию, было бы круто)

[@Olga-pc3bm]

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

[@OStrekalovsky]

Всё это замечательно, но производительность опять встанет во главу угла, причём в разных видах: если нужны транзакции на несколько агрегатов - непонятно как это сделать без нарушения инкапсуляции сервисов, каждый из которых сам управляет сохранением своего агрегата. Аналогичные проблемы и с сохранением и вычитыванием больших агрегатов. Видимо правду нужно искать в поиске тонкой грани между поддерживаемостью кода (поддержание выполнений бизнес правил) и производительностью. Такое ощущение, будто DDD делали прям под документно-ориентированные БД, в которых нормально сохранять огромные объекты. С реляционными БД будет много мороки.

[@sevaelunin]

Наоборот, с RDBMS даже проще бывает. Если два агрегата надо обновлять транзакционно, то можно использовать синхронную обработку доменных событий (шарить контекст БД между обработчиком команды/прикладным сервисом и обработчиком доменного события) Можно у MS почитать раздел про доменные события в цикле eShopOnContainers или в блоге Джимми Богарда Это если у вас два агрегата в одном ограниченном контексте/сервисе. Если нужна транзакционность между агрегатами разных контекстов, то что-то не так с границами контекстов.

[@Olga-pc3bm]

1.Транзакций для нескольких агрегатов быть не может. Значит поплыла модель. 2. Больших агрегатов, которые могут аж выгрести всю базу быть не может. Значит вновь проблемы с моделью и определением контекста. Что делать? Читать Эванса, первоисточник. 3. Для повышения производительности покупается много серверов, много баз данных и проектируется система, которая скалируется. А транзакции нужны в крайне редких случаях, хотя пихают их везде. Транзакционная целостность данных - это маловажная вещь в 90% случаев. Всё удалить или добавить можно руками. И важная в 10%, когда это действительно транзакция ( перевод денег со счета на счёт), а не просто мы не умеем писать код (выгребание данных без грязного чтения или каскадное удаление). 4. ДДД не зависит от реализации хранения и прочей инфры. ДДД это про проектирование (design). 5. Нормальные архитекторы не использую RDBS в тех частях данных, которые транзакции не требуют. Не нужно в RDBS хранить ФИО, логи, продукты и прочую хрень. В них нужно хранить переводы бабла со счета на счет, передачу товаров со склада на склад, прочую передачу чего-то куда-то во времени и.... по сути всё. А не информацию и состояние объектов.

[@rm-rf88]

@@Olga-pc3bm а чем это хранение ФИО в RDBS не подходит? Перевод бабла это вообще событие, а состояние счета хранить не нужно уже получается? В монгу все пихнем, да?

[@БогданГуківський]

@@Olga-pc3bm 1. Может, как упрощение, вместо построения саги, если производительность позволяет. 5. Если RDBS позволяют получить необходимую производительность - они почти всегда лучший выбор. Не стоит тянуть супер технологии для задач, которые их не требуют, иначе цена разработки будет крайне завышена.

[@shebbyman9843]

Не понял отличие полноты от чистоты в "DDD-трилеме". 1:12:20 По объяснению выходит, что это одно и то же, а оригинального материала от Владимира Хорикова не нашел. "Полнота - вся бизнес-логика содержится в модели и не делегируется сервисам" "Чистота - модель изначально содержит все номера телефонов и ей не надо ни к кому обращаться, чтобы этот список получить" Это одно и то же по сути.

[@sevaelunin]

В полной модели вы передаете в метод агрегата доменный сервис как интерфейс для взаимодействия внутри агрегата с БД или внешними сервисами. В чистой модели вы передаете в метод только результаты взаимодействия с БД/внешними сервисами.

[@БогданГуківський]

На практике абсолютная чистота модели приносит крайне мало профита. Если в модели есть оут мемори зависимости - то они есть, и их не нужно выносить за пределы модели. Все что можно сделать - это разделять в коде чистую и не чистою часть домена на раздельные тестируемые модули. ИМХО, DDD-трилема надуманная проблема, иллюзия выбора там, где его нет. У домена нет задачи быть чистым, он должен моделировать правила мира, в котором работает аппликейшн, и если для поддержания этих правил нужно нарушить чистоту - значит нужно, без каких либо сожалений.

[@DDDevotion]

Очень интересно) Заходите к нам - у нас много интересного.