Генри  Форд чуть не прогорел на своей фразе про пятьдесят  оттенков черного. General Motors стала предлагать разноцветные модели  Chevrolet, Pontiac, Buick, Oldsmobile и Cadillac — и не прогадала. Глядя  на это, даже упрямый Форд изменил свое мышление  — и разработал новый  Ford A, вернувший его на автомобильный Олимп. Бывают времена, когда  парадигма мышления должна стать новой —  ибо человек умирает тогда,  когда перестаёт меняться ©Генри Форд.  Пришло время и для  разработчиков. Command Query Responsibility Segregation (CQRS) и Event  Sourcing (ES) уже не миф — они реально работают. Конечно, не для всех  задач — как и классический черный цвет Форда, PHP никуда не исчез и  нужен по-прежнему. Но теперь уже есть задачи, где мы встречаемся с CQRS и  ES чаще, чем нам кажется. Антон Шабовта на PHP Russia 2021  расскажет, как смена парадигмы и взгляд с другой стороны помогают  разработчикам. А перед конференцией мы расспросили Антона подробнее о  его новых взглядах на разработку, PHP и, конечно, о CQRS и ES. — Антон, расскажи о себе и о своей работе. Чем ты занимаешься? —  Последние 12 лет я в коммерческой разработке и большая часть времени  занимался проектами связанными с E-Commerce. Но 3 года назад мне  захотелось применить свои знания в проектах другой сферы. Так я пришел в  сервисную команду Onliner’а — это крупнейший белорусский медиа портал с  огромным количеством сервисов. Нашу команду разработки можно условно  разделить на две части. Команда каталога занимается основном продуктом —  каталогом товаров.  В нем почти два миллиона позиций от тысяч магазинов  — а это десятки миллионов товарных позиций. И этот действительно  большой и сложный E-Commerce продукт, который  продолжает развиваться и  расти. Команда сервисов, в которой я и работаю, занимается  остальными нашими продуктами. Это  сервисы аренды и продажи квартир,  сервис поиска и предоставления услуг, авто- и мотоклассифайды и т.д.  Есть еще огромный новостной портал с кучей инфраструктуры и сервисов  вокруг него (комментарии, система личных сообщений, идентификация  пользователей и пр.) Конечно, есть и сервисы, связанные с оплатой  банковскими карточками и т.д. То есть это огромное скопление проектов в  разных сферах и предметных областях.  По сравнению с E-Commerce  это совершенно другой мир и другие задачи. И мне было интересно понять,  могу ли я применить знания из предыдущих проектов — подстроить,  преобразить и переложить опыт из одной сферы на другую. Но и новому тоже  хотелось учиться. — Твой доклад на конференции будет про долгий путь к CQRS и Event Sourcing. Это связано с твоей карьерой разработчика? —  Да. Впервые я столкнулся с подходами Command Query Responsibility  Segregation (CQRS) и Event Sourcing (ES) еще при работе с E-Commerce в  2015 году. И это стало важной вехой в моей карьере разработчика.  Информации о CQRS и ES было много, но столько же возникало вопросов,  мифов и недопонимания. Что именно представляют собой эти технологии? Как  их использовать? Где стоит применять и какие проблемы они действительно  призваны решать? Так вот одна из моих целей на PHP Russia 2021 —  развенчать часть этих мифов и показать, что мы сталкиваемся с CQRS и ES  намного чаще, чем кажется, даже если раньше мы никогда не слышали эти  слова. В 2017 году, проработав два года с CQRS и ES, я сделал  доклад об этом  в рамках митапов Минской PHP User Group. Но, пересмотрев  слайды, я понял, что в корне неверно подходил к объяснению этих  технологий. За пять лет мое понимание значительно преобразилось,  и я  надеюсь, что на этот раз смогу лучше объяснить. Так что во многом доклад  для PHP Russia 2021 — это еще и работа над ошибками. —  У тебя  есть опыт с Erlang и Java (про С/С++, C# и Python знаем), или же ты  целенаправленно изучаешь практики оттуда, чтобы рассмотреть их для PHP? —  По-разному, it depends. Исторически так сложилось, что многие книги по  архитектуре программных систем используют примеры и понятия из  Java-мира. И чтобы не упустить какие-то ключевые моменты и важные  нюансы, пришлось разбираться в Java. Недавно стряхнул пыль с этих  знаний, когда искал решения для своих проектов и разбирался с  фреймворками Axon и Akka. В целом же, практики из одного языка, по  крайней мере, из Java, очень легко и просто переносятся на PHP.  С#  я начал изучать, когда разбирался в устройстве фреймворка NServiceBus. В  нем реализовано много классных решений, связанных с MBA (message-based  architecture), SOA (service-oriented architecture) и сопутствующими  технологиями. Erlang — это вообще отдельная история. Интерес к  нему пришел в процессе изучения классического понятия ООП  (объектно-ориентированного программирования) от Алана Кея и модели  экторов. Это реально классный язык, совершенно непохожий на другие. Не  могу сказать, что готов сейчас писать на нем production ready код, но  изучать его концепции, конечно, продолжу. — Получается, что ты изучаешь, условно говоря, не какие-то языки, а перенимаешь практики из других языков, которые там успешны? —  Не всегда то, что успешно работает в одном языке, будет работать в  другом. Но в процессе изучения я вижу, когда какие-то практики можно  попробовать.  — Помогает ли знание других языков лучше писать на PHP? —  И да, и нет. С одной стороны, многие практики и идеи можно (и нужно!)  применять в PHP, особенно из близких по духу по подходам языков (Java,  C#). ООП-модель PHP очень близка к этим языкам. К тому же мир разработки  в PHP очень сильно изменился, например, после выхода фреймворка Symfony  2. Команда Symfony проделала колоссальную работу по прививанию  паттернов проектирования в PHP community. Но большинство паттернов были  придуманы не для PHP, а для других языков, в том числе, для Smalltalk и  Java. С другой стороны, из-за технических ограничений, некоторые  интересные концепции невозможно развивать и применять в PHP. Например,  многие подходы из мира функционального программирования и модели  экторов, пропагандируемые Erlang’ом. Мы ограничены технологиями своего  времени. Но, возможно, часть этих технологий в будущем можно будет  применить и в PHP. — Когда нужны подходы из других языков, а когда лучше по старинке или попроще? — Это самый сложный вопрос, независимо от технологии, который только может себе задать разработчик. И простого ответа тут нет. Я  стараюсь для себя придерживаться KISS-принципа, то есть «Keep it  simple, stupid»: если есть возможность делать что-то проще и не  усложнять, то лучше так и сделать. Такие серьезные подходы как CQRS и ES  несут много изменений не только в коде, а даже в самой модели мышления  программиста. Мы ставим себя в определенные рамки, и за это придется  платить. Не бывает серебряной пули в программировании. Поэтому  внедрять CQRS и ES не глядя, просто потому что можем — очень-очень  плохая идея. Можно получить намного больше проблем, чем пользы. Конечно,  когда-то это оправдано, но не всегда. Поэтому нужно хорошее изучение  problems face, чтобы понимать, зачем мы внедряем эту технологию и какую  проблему бизнеса пытаемся ею решить.  — Что дают эти подходы разработчику, в чем помогают?  CQRS  и ES ориентированы на то, чтобы разработчик больше думал именно о  поведении системы в первую очередь, а не о хранении. Это очень часто  помогает найти существующие взаимодействия, которые не видны на уровне  данных. Эти подходы проявляют эти взаимодействия и позволяют с ними явно  работать, упрощая какие-то штуки. Но в то же время очень сложно  ментально перестроиться и сменить парадигму мышления.  — Поэтому нет популярных фреймворков для CQRS и ES?  —  Строго говоря, их не может быть. Говоря о фреймворках, мы  подразумеваем, в первую очередь, инверсию управления. Когда мы работаем с  фреймворком, не мы вызываем его код, а он вызывает наш. Это вопрос  инфраструктуры. С другой стороны, ES и CQRS неразрывно связанны  именно с моделированием домена приложения, то есть это доменная модель. А  хорошая доменная модель не должна зависеть от фреймворка. Но мы можем  ее внедрить в любой фреймворк, с котором нам удобно будет работать. Создатель этих подходов Грег Янг любит повторять в своих докладах, что для реализации ES и CQRS достаточно двух операций: Сравнение по образцам (pattern matching); Лево-ассоциативная свертка списка (left fold) — функция высшего порядка. И  многие языки поддерживают эти операции уже на уровне стандартной  библиотеки. Например, тот же left fold в PHP существует как  array_reduce, и дополнительно можно придумать другие варианты  реализации.   Pattern matching, к сожалению, полностью в PHP еще  не реализован, хотя работа в этом направлении ведется. Но та малая часть  из pattern matching, которая нужна для имплементации ES, легко  эмулируется в user-land коде.  Есть также много технологий,  которые работают вокруг и рядом с CQRS и ES — те же message-based  architecture и service-oriented architecture. Для этих технологий уже  есть фреймворки, хотя достаточно популярных в PHP-мире пока не  сформировалось. Какие-то работы сейчас ведутся и какие-то фреймворки  вырастают. Но enterprise production ready, решений уровня того же  NServiceBus в C# либо Axon в Java, пока в PHP не сложилось. Ждем! — А есть ли учебник, где на пальцах правильно объясняются эти подходы? —  Изучать CQRS и ES стоит с просмотра докладов отца-основателя Грега  Янга, с его публичных выступлений, статей, материалов и записей в блоге.  Он подробно пишет, как он пришел к этим подходам, и из каких проблем  они возникли. Для продолжения есть его книга «Versioning in an Event  Sourced System» — там вы найдете для себя кое-какие нюансы. Много  материалов по ES и CQRS подходам можно найти в документации Microsoft. У  них есть даже более развернутый вариант, который вышел в виде отдельной  книги «Exploring CQRS and Event Sourcing». Предисловие к книге написал  тот же Грег Янг.  Еще этим технологиям много внимания уделяют те,  кто пишут и работают с DDD-подходом (Domain-Driven Design), например,  Vaugh Vernon. И у него есть книга «Implementing Domain-Driven Design», в  которой большая глава посвящена именно ES и CQRS. — Кому можно верить, не проверяя, в мире разработки и PHP: Фаулеру, Мартину, кому-то еще? —  Никому. Серьезно. Мартин Фаулер, Роберт Мартин, тот же Грег Янг, а  также другие авторы тратят сотни часов времени, чтобы поделиться своими  знаниями в статьях, в записях блогов, в докладах и в книгах. Иногда  пишутся целые научные работы по каким-то подходам. Это действительно  круто, что мы имеем доступ к этой информации. Но часто  разработчик, прочитав статью или увидев доклад о той или иной  технологии, тут же бежит её внедрять на своем проекте, забывая о  проблеме, которую она должна решать. DDD, CQRS, ES и все другие сложные  подходы появились для решения конкретных проблем, с которыми столкнулись  их создатели. Вот что должно быть первоочередным для хорошего  разработчика. Я считаю, что безоговорочное доверие авторитетам,  этот «аристократичный» синдром, наравне с «культом карго» — это одна из  ключевых проблем современного IT. — То есть ты сам не придерживаешься этого всего? —  Я, естественно, изучаю работы всех именитых разработчиков и с интересом  наблюдаю за развитием технологий. Про них надо знать и помнить, но  нельзя их применять не глядя. Надо сначала столкнуться с проблемой.  Понять, что одна из технологий, про которую ты читал, вспомнил, увидел,  решает эту проблему. И только тогда думать, как ее внедрять, и  действительно ли она решит эту проблему. Очень часто наш мозг нас  немножко обманывает. Он помнит про какое-то изящное и красивое решение,  про какую-то очень крутую технологию, и пытается подогнать нашу проблему  под нее. С этим, конечно, нужно бороться. И понимание того, когда нужна  та или иная технология, приходит только с опытом, с годами работы и  ошибок. Мы, программисты, реализуем идеи, с которыми к нам  приходит бизнес. У бизнеса есть какая-то проблема, мы придумываем  решение. Разработчики должны исходить из проблем бизнеса, а не  использовать технологию ради технологии, для красоты. — Чего ты ждёшь от конференции в этом году? Онлайн-формат  — это, конечно, интересно и круто. Но пока я не могу сказать, что он  может заменить оффлайн. Поэтому в первую очередь я жду, конечно,  отличных докладов, много профессионального общения и интересных  обсуждений в кулуарах. Я считаю, что эти обсуждения даже более ценны,  чем доклады. Зажав спикера в кольцо, можно ему задать важные вопросы,  которые не всегда есть время раскрыть в докладе. Очень часто какие-то  действительно problem spaces остаются за рамками докладов.  Еще я жду новостей! С такими переносами, я думаю, к моменту начала конференции у нас их будет немало. Хотелось бы знать: Что нас ждет в PHP 9? Какая  будет следующая большая цель на этот релиз? Возможно, это будет  асинхронный PHP — это важный лично для меня вопрос. На прошлом PHP  Russia я читал доклад именно про асинхронный PHP. Вопрос,  волнующий всех: появятся ли у нас Generic-типы? Недавно добавили  Union-типы. Скорее всего, скоро добавят пересечения, но Generic — это  то, что возникает так или иначе в вопросах на каждой PHP-конференции. И афтепати, конечно! PHP Russia 2021   пройдёт в гибридном формате —будет и офлайн, и онлайн. Онлайн-зрители   смогут задавать вопросы спикерам в зале, принимать участие в дискуссиях  и  участвовать в активностях на стендах партнёров. Мы с нетерпением ждём нашу встречу в офлайне 28 июня 2021 года. Сегодня последний день до повышения цены — сейчас стоимость очного участия 27 000 рублей Подписывайтесь на наши соцсети, чтобы быть в курсе новостей (FB,VK,Telegram-канал,Twitter), общайтесь с коллегами в чате. PHP, Yii