ДИНО ЭСПОЗИТО
Тренер с многолетним опытом и консультант экстра-класса. Дино – автор нескольких популярных книг издательства Microsoft Press, которые способствовали профессиональному росту тысяч .NET-разработчиков и архитекторов. Будучи техническим директором одной быстрорастущей компании, занимающейся разработкой ПО и мобильных сервисов для профессионального спорта, Дино является техническим евангелистом разработки под Android и на Kotlin в JetBrains, а также членом команды, которая ведет WURFL, базу данных с информацией о мобильных устройствах, которая используется такими компаниями, как Google и Facebook.
Добрый день, Дино. Вы будете проводить мастер-класс на тему CQRS и Event Sourcing. Не могли бы вы рассказать об этих подходах?
То, что я наблюдаю сейчас, что CQRS – это самый эффективный шаблон проектирования практически любого приложения. CQRS говорит о применении точно разделенных стеков для команд и запросов. Это означает, что мы имеем две более простых модели предметной области вместо одной сложной, охватывающей оба этих аспекта. Стек запросов в CQRS решении очень прост и обычно состоит из чистого слоя запросов верхнего уровня в LINQ или ADO.NET. Стек команд в отличие от привычного, но необязательного подхода отображает бизнес логику в задачах и выполняет их по средствам команд, событий и их синхронизации.
Как холод для торта, Event Sourcing основан на сохранении всех событий, связанных с сущностями предметной области, и использования их в качестве приоритетного источника данных в приложениях. Вы не храните реляционную модель; вы только регистрируете все события, которые связаны с изменениями в системе, и воспроизводите эти события последовательно для получения актуального состояния сущности на определенный момент времени. Когда дело доходит до фактической реализации вы сможете выделить довольно мало дополнительных деталей, но это именно те, которые вы обнаружите в классе.
Для решения каких задач вы посоветуете использовать CQRS, а где лучше применить традиционный CRUD?
Честно говоря, я не думаю, что есть какие-то определенные слабые стороны в CQRS. CQRS – это шаблон, который предлагает вам использовать два отдельных уровня: один, заполненный моделью и сервисами для считывания, и один с моделью и сервисами для исполнения команд. А что такое модель – или это объектно-ориентированная модель, или библиотека функций, или коллекция объектов передачи данных – в целом это детали исполнения. Опираясь на это утверждение, практически для любой системы выгодно использование CQRS, и программирование не требует применения каких-то новых подходов, чем ранее. Также это не значит, что вам придется изучать что-то новое и страшное. В заключение, CQRS, в своем роде, – это лучший и более гибкий способ применения CRUD.
Многие годы DDD рассматривался как простое решение для сложных бизнес сценариев. Какая связь между DDD and CQRS?
CQRS можно рассматривать как шаг вперед от Domain Driven Design сокращенно DDD. DDD первоначально продвинул идею о целой, всеохватывающей модели, способной поддерживать все аспекты и процессы данной предметной области. Однако уже более десяти лет люди изо всех сил пытаются строить системы в соответствии с директивами DDD. Некоторые проекты, в которых применялся DDD, в итоге заработали; некоторые проекты провалились. Также можно рассказать и истории успеха, но многие до сих пор верят, что трудно заниматься проблемно-ориентированным проектированием, несмотря на значительные выгоды, которые оно может принести. Дело в том, как мне кажется, что для многих людей, понимание того, что DDD приносит пользу, гораздо менее конкретно, чем понимание ущерба, который может возникнуть в результате применения DDD и провала. В этом контексте CQRS ломает привычный подход. Одна всеохватывающая модель часто слишком сложна и влечет риски. Что, в конце концов, вы делаете в любом приложении? Все что вы делаете – это выполняете команды пользовательского интерфейса и запрашиваете данные. Давайте тогда разделять эти два уровня. В конечном итоге, именно это и позволяет сделать CQRS — выделить зоны ответственности, связанные с выполнением команд и чтением данных.
Вы являетесь автором множества книг по разработке ПО. Ваша последняя книга по архитектуре корпоративных приложений – просто «хит книжных полок». Какое сообщение вы хотите передать вашим читателям?
Как разработчики мы хорошо знаем законы Murphy и в частности законы Murphy по разработке программного обеспечения. Мой любимый гласит: «Ничего еще не создали в соответствии с графиком или в рамках бюджета». И вы мало что с этим можете сделать, кроме того, чтобы изучать и узнавать как можно больше о предметной области, чтобы вашу модель назвали максимально похожей. В конечном счете, мы пишем программы, чтобы максимально воспроизвести процессы реального мира. Мы должны знать процессы реального мира; мы должны полностью понимать механизмы существования предметной области; мы должны владеть языком экспертов; и все это нам нужно для того, чтобы получить представление о требованиях и спроектировать программный продукт.
Кто является целевой аудиторией вашего мастер-класса? Кто извлечет большую пользу – начинающие разработчики или опытные?
На первый взгляд, я бы сказал, что архитекторы и старшие разработчики – это идеальные слушатели мастер-класса. Но затем, я также могу сказать, что ничего в этом классе не будет абсолютно новым в том смысле, что большинство архитекторов если не пробовали на практике, то хотя бы слышали о большинстве рассматриваемых тем. Так что я бы остановился на том, что любой .Net разработчик найдет этот класс полезным для себя. Также этот мастер-класс поможет любому, кто хочет стать архитектором. Возможно, ожидания начинающих и опытных разработчиков не будут одинаковыми, но каждый, я думаю, вынесет много полезного из этого класса. Чтобы укрепить эту позицию позвольте мне рассказать вам анекдот. Это случилось на TechEd Europe в 1999 году во время моего первого выступления на английском языке. Я был в смятении, взволнован и напуган, и я надеялся, что зал будет пуст. Но когда я вошел в аудиторию, я обнаружил, что Don Box – в то время Бог Windows/COM разработчиков – уже занял место в первом ряду. Он ждал меня и сказал: «Я здесь, чтобы учиться у тебя». «Don – ответил я – ты как Бог. Чему ты собираешься учиться у меня?» И он произнес фразу, которая время от времени всплывает в моей голове: «Дино, это все, что касается перспектив!»
Я уверен, что каждый, посетивший мастер класс, найдет что-то уникальное и ценное для себя на перспективу – будь он начинающим или опытным разработчиком.
Автор: Evgenia_s5
