Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали

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

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

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

4. Интересные факты
• «Сделать продукт» – в 6 раз дольше, чем «написать код»
• Норма рисков в разработке ПО 250%-300% (поэтому нормальный
fixed price – дорогой, а не нормальный – рискованный)
• Код в 10 раз чаще читают, чем пишут
• Производительность разработчиков по разным данным
отличается в 6-28 раз
• Регрессионное тестирование может никогда не закончиться
• Для разработки ПО нет хороших стандартов или ГОСТов

5. The Blue Book

6. DDD

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

8. Ключевые термины DDD
• Bounded Context
• Ubiquitous Language
• Entity
• Value Object
• Specification

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

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

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

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

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

15. Как называется?
• Side-effect-free
• Immutable
• Может компоноваться

16. CQRS over HTTP
• GET– это Query
• POST/PUT/PATCH/DELETE – это Command

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

18. Вопросы