ݺߣ

ݺߣShare a Scribd company logo

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

•Download as PPTX, PDF•
•
M
Max Arshinov

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

1 of 18
Downloaded 10 times
Рентабельный код Как мы попробовали 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, но надо понимать как они работают
Вопросы

More Related Content

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

  • 1. Рентабельный код Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали
  • 2. Задачи • Повысить скорость разработки новой функциональности без ущерба для существующей • Снизить время подключения нового специалиста • Повысить bus factor • Повысить качество планирования, «усреднить» производительность членов команды • Снизить количество багов и регрессии в каждой итерации
  • 3. Обязательно к прочтению всем ведущим разработчикам и техническим менеджерам
  • 4. Интересные факты • «Сделать продукт» – в 6 раз дольше, чем «написать код» • Норма рисков в разработке ПО 250%-300% (поэтому нормальный fixed price – дорогой, а не нормальный – рискованный) • Код в 10 раз чаще читают, чем пишут • Производительность разработчиков по разным данным отличается в 6-28 раз • Регрессионное тестирование может никогда не закончиться • Для разработки ПО нет хороших стандартов или ГОСТов
  • 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, но надо понимать как они работают