рентабельный код

Рентабельный кодКак мы попробовали DDD, CQRS и Event Sourcing и какие выводы

сделали

Задачи

• Повысить скорость разработки новой функциональности без ущерба для существующей• Снизить время подключения нового специалиста• Повысить bus factor• Повысить качество планирования, «усреднить»

производительность членов команды• Снизить количество багов и регрессии в каждой итерации

Обязательно к прочтениювсем ведущим разработчиками техническим менеджерам

Интересные факты

• «Сделать продукт» – в 6 раз дольше, чем «написать код»• Норма рисков в разработке ПО 250%-300% (поэтому нормальный

fixed price – дорогой, а не нормальный – рискованный)• Код в 10 раз чаще читают, чем пишут• Производительность разработчиков по разным данным

отличается в 6-28 раз• Регрессионное тестирование может никогда не закончиться• Для разработки ПО нет хороших стандартов или ГОСТов

The Blue Book

DDD

B for Behavior

• Вы моделируете предметную модель, а не структуру ORM• Вы не делаете пустых конструкторов• Вы не пренебрегаете инкапсуляцией• Вы определяете поведение, а не структуру хранения

Ключевые термины DDD

• Bounded Context• Ubiquitous Language• Entity• Value Object• Specification

DDD

• ОЧЕНЬ дорого• Работает хорошо в устоявшихся бизнес-процессах• Иногда – это единственный способ сделать то, что нужно• Плохо масштабируется• Сложно реализовать в высоконагруженных приложениях• Плохо работает в стартапах• Не подходит для построения отчетов• Требует особого внимания с ORM• Слова Entity лучше избегать, потому что его все понимают по своему• С LINQ стандартная реализация Specification «не работает»

CQRS, CQRS, who the f*ck is CQRS?

Вам скорее всегоне нужен Event Sourcing

• Мы вообще не обсуждаем эту тему сегодня, потому что вы скорее всего не разрабатываете ПО для банка• А если разрабатываете, то у вас уже есть Audit Log и нет нужды

рассказывать то, что вы уже знаете

CQRS –более простой способ делать то, что вы уже

умеете

In / Out

• Принимает на вход и возвращает DTO (желательно immutable), а не доменные объекты• В отсутствии команд Query всегда возвращает одинаковый

результат• Команды изменяют состояние системы

Как называется?

• Side-effect-free• Immutable• Может компоноваться

CQRS over HTTP

• GET– это Query• POST/PUT/PATCH/DELETE – это Command

CQRS

• Event Sourcing требует CQRS, но не наоборот• Дешево• Подходит везде• Масштабируется• Не требует 2 хранилища данных. Эта одна из возможных реализаций, а не обязаловка• Обработчик команды может возвращать значение. Если не согласны спорьте с

Грегом Янгом и Дино Эспозито, а не со мной• Если обработчик возвращает значение он хуже масштабируется, однако есть

async/await, но надо понимать как они работают

Вопросы