Пятый выпуск PHP подкаста: Domain Driven Design, основы CQRS, Event Sourcing и как это использовать вместе.

СКАЧАТЬ mp3 (30Мб)

DDD = Domain Driven Design

Коротко — подход, при котором создаваемое приложение максимально точно отражает специфику реальных бизнес-процессов. Это включает интерфейсы взаимодействия с приложением, нейминг методов, разделение на группы связанных контекстов. Такой подход гарантирует взаимопонимание того что делаете вы как разработчик и эксперта в моделируемом вами бизнесе.

Основы CQRS (command-query responsibility segregation)

Архитектурный подход разработанный Грегом Янгом. Усложнение кода. CRUD в противовес. CQRS — это желаемый шаг после нехватки организации кода при CRUD-подходе. CQRS предлагает разграничить логику команд (command) и запросов (query). Их независимость способствует масштабированию. CQRS хорошо согласуется с событийно-ориентированными подходами (Event Sourcing). Использование CQRS должно быть ясно обосновано в проекте, т.к. этот подход умножает сложность проекта. Как правило CQRS имеет смысл применять для решения локальной проблемы (проблемы связанного контекста — Bounded Context — в терминах DDD) в большом проекте, т.е. использовать CQRS для всего проекта зачастую избыточно.

Реальные сферы, где CQRS может быть полезен:

• финансы и другие сложные транзакции;
• высоконагруженные сервисы с потенциально сложными Query (помним про возможность использовать Reporting Database).

Event Sourcing

Все приложения которые мы пишем отражают текущее состояние системы. Но иногда этого недостаточно и хочется узнать а как мы пришли к этому состоянию. Краеугольная сущность в Event Sourcing — это событие (Event). Ключ к пониманию Event Sourcing — изменение состояние системы возможно только посредством обработки событий. События изменяют состояние системы. Сохранив последовательность событий мы можем восстановить состояние системы на любой момент времени. Очевидное преимущество — у нас есть лог всего того, что происходило. Второе преимущество, что этот лог легко использовать в приложении для регенерации состояния системы. Фактически, это резервная копия в виде журнала. Другое ощутимое преимущество — возможность вносить правки задним числом и потом восстановить состояние. Важно правильное проектирование событий! Главное правило для меня — возможность по событию вернуть текущее состояние системы.

Как все это использовать вместе?

Предостережение

Если у вас на проекте горят все дедлайны, то не спешите внедрять все то, о чем рассказал в этом подкасте. Будьте осмотрительны.

https://github.com/ScriptFUSION/Mapper

Инструмент для удобного меппинга разноформатных массивов данных к одному формату.

Анонс подкаста Golang: от пеленок к звездам