Что такое cqrs php
Мир изменился — CQRS и ES встречаются в PHP чаще, чем кажется
Генри Форд чуть не прогорел на своей фразе про пятьдесят оттенков черного. 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), общайтесь с коллегами в чате.
CQRS и микросервисы в продуктовой разработке
Как спроектировать продукт, чтобы не зарыть деньги в землю
На каком этапе создания продукта или системы подключать архитектурное проектирование системы, чтобы потом не было мучительно больно за потраченные деньги? Как решить, совмещать ли CQRS и микросервисы.
Эта статья для представителей бизнеса с запросом на разработку ИТ-решения. Мы подскажем, как запустить продукт и избежать неоправданных затрат, связанных с архитектурой. А также посмотрим, как использование CQRS поможет при реализации функционала в разных клиентах приложения, и являются ли микросервисы той самой панацеей.
Коротко о CQRS
CQRS (Command-Query Responsibility Segregation) — шаблон, применяемый при разработке систем, который гласит, что любой метод системы может быть либо запросом (не изменяющим состояние системы), либо командой (изменяющим состояние системы). Как показывает практика, это один из самых часто применяемых шаблонов при разработке ПО. Его можно применять на разных уровнях и в различных ситуациях. Например, классическое разделение систем на OLTP/OLAP, когда данные пишутся часто в OLTP-систему, а читаются из OLAP-системы, является ни чем иным как применением шаблона CQRS в архитектуре БД.
В “древние” времена (начало 2000 годов) популярные системы подталкивали к применению CQRS. Например, при использовании Interbase/FirebirdSQL рекомендуется использовать разные типы транзакций для чтения и записи. В современном мире очень часто встречается случай сосуществования двух систем на разных уровнях архитектуры. Например, может быть разделение на уровне различных систем, когда личный кабинет клиента на сайте реализует только Query-функциональность, а все изменения происходят в CRM-системе внутри компании через заранее определенные интерфейсы Command. Можно найти примеры использования CQRS на уровне архитектуры JS приложения. Кто бы мог подумать несколько лет назад, что слова архитектура и JS будут использоваться в одном приложении… Хотя, возможно, это излишний стеб.
Две крайности при разработке
Типичная ситуация: A Big Ball of Mud
Очень часто встречается эволюционный подход к разработке. Как правило, сначала разрабатывается MVP без проработки архитектуры и анализа нефункциональных требований, затем начинается долгий этап эволюционных доработок. В итоге мы получаем плохо функционирующую систему, которую трудно дорабатывать. В критических случаях — еще и написанную с использованием языка программирования, для которого очень трудно найти разработчиков. Примечательно, что к таким последствиям можно прийти вне зависимости от опытности команды и качества менеджмента. Все стараются делать лучшее в имеющихся на тот момент условиях, но с течением времени получается результат далекий от идеала.
По нашему опыту в случае отсутствия регулярной практики по архитектурному проектированию, неизбежно наступает момент когда систему приходится переписывать целиком. На это тратится больше сил и средств, чем на всю предыдущую разработку. И самое страшное, что приходится переучивать всех пользователей для работы с новой системой. В некоторых случаях это сопоставимо по стоимости с разработкой самой системы.
В таких ситуациях от основателей и стейкхолдеров бизнеса можно услышать фразы: “Нам бы побыстрее выйти в релиз и получить первых клиентов. А потом уже давайте думать, что делать с клиентами и как улучшать наш продукт”. При таком подходе, когда случается реальный наплыв первых клиентов, система начинает валиться, и вся команда начинает тушить пожары. В такой ситуации иллюзия “хорошей жизни” внезапно развеивается. Разработчики и все держатели контекста постепенно покидают команду. Клиенты недовольны. В результате бизнес рушится из-за того, что не смог масштабироваться.
Микросервисы не спасут
В последнее время микросервисы очень популярны. При этом некоторые заказчики на волне хайпа требуют, чтобы все было реализовано с использованием микросервисной архитектуры, не зная реальную стоимость ее применения. Чтобы получить пользу, надо уметь правильно микросервисы готовить. Не достаточно просто сделать несколько независимых проектов и назвать это микросервисами.
При разделении системы на микросервисы возникает много вопросов по взаимодействию систем. Например, как отследить цепочку вызовов различных сервисов, которая привела к конкретной ошибке. Или как понять, какой сервис сейчас является узким местом в работе системы. Эти вопросы с разной степенью успешности решаются либо готовыми инфраструктурными решениями (Elastic для логгирования), либо под них надо разрабатывать какие-то свои инфраструктурные сервисы. К примеру, балансировщик, который учитывает особенности бизнес-логики при маршрутизации запросов. Эти проблемы характерны не только для микросервисных систем, но и для всех распределенных систем.
В большинстве случаев, крупные вложения в разработку инфраструктуры, особенно на начальном этапе создания системы, не оправданы. Не известно, будет ли система работать сколько-нибудь продолжительное время, или бизнес-идея не оправдает себя, и проект будет закрыт. Мы не знаем, сколько пользователей к нам придет. Известны случаи, когда в большом проекте стоимость развертывания всей инфраструктуры для нескольких сервисов в нескольких конфигурациях, проверка работоспособности, масштабируемости и т.д. превышала 1 млн рублей. В среднем проекте реализация бизнес-логики стоит ощутимо меньше. Все же это расходы, которые на данном этапе нецелесообразны.
Кроме того, грамотно разделить систему на независимые микросервисы на начальном этапе, как правило, не получается по причине того, что еще не известен ни точный функционал проектируемой системы, ни структура предметной области. Следовательно, неправильно выбранное разделение по сервисам приводит к сложностям и неминуемо к дополнительным расходам при реализации необходимых сценариев работы системы. В некоторых случаях — и к полной невозможности корректного функционирования системы. Система, построенная на микросервисах, является частным случаем распределенной системы и подвержена действию CAP-теоремы. И если заранее не заложить механизмы обеспечения целостности данных, про что сейчас очень часто забывают, то в реальной эксплуатации можно получить очень много неприятных сюрпризов в виде потери или рассинхронизации данных.
Золотая середина
Продуманная архитектура — залог успеха
При разработке традиционных монолитных систем возникают те же самые вопросы по грамотному описанию/разделению предметной области. Неправильное разделение системы на слабо связанные контексты приведет к нежелательным последствиям: к очень сложному внесению изменений, невозможности отследить и проверить все сценарии поведения. Ошибки будут возникать и нарастать как снежный ком в самых неожиданных местах.
Останется ли заказчик/пользователь доволен работой системы зависит от того, насколько грамотно она спроектирована. Поэтому крайне важно задуматься о проектировании системы как можно раньше. Причем, для этого, необходимо понять работу системы на всех уровнях, кто и как будет пользоваться системой.
Пример
Скажем, мы делаем интернет-магазин, но заказчик совершенно забыл про то, как работает доставка и что кроме того, чтобы продать необходимо еще и укомплектовать заказ, и для этого надо сделать удобный интерфейс комплектовщика или сделать интеграцию разрабатываемой системы с системой складской логистики. Говоря простым языком, если мы не представляем себе хотя бы основные бизнес-процессы, в которых будет принимать участие наша система (т.е. бизнес-архитектуру), то мы можем упустить очень большую часть потребностей и оказаться в ситуации, когда все вроде сделали правильно, но пользоваться системой нельзя и надо где-то искать дополнительные средства на доработку.
Не редкость в таких ситуациях отсутствие средств, поскольку оставшиеся к этому моменту бюджетные ресурсы были потрачены на дополнительные, не столь критичные функции. Не проработав до конца все взаимодействия разрабатываемой системы с другими системами (т.е. архитектуру решения), мы можем начать делать дорогие и бессмысленные на данный момент вещи, например разрабатывать свою CRM-систему в то время, когда заказчику не надо никакой особенной функциональности и можно использовать готовое решение. И только проработав и поняв окружение разрабатываемой системы, можно обоснованно принимать решение о выборе программной архитектуры, разделения системы на слабосвязанные контексты и т.д.
Так с чего начать?
На практике для выработки таких архитектурных решений хорошо помогает одно- или двухдневный воркшоп с заказчиком, на котором прорабатывается не только архитектура решения, но и low-fidelity дизайн системы и основные сценарии использования. В случае со стартапами чрезвычайно важным шагом является проработка Business Canvas вместе с заказчиком (если его еще нет) для того, чтобы все стороны поняли жизнеспособность идеи. Не исключено, что результатом будет закрытие проекта сразу после воркшопа: он поможет стейкхолдерам увидеть несостоятельность бизнес-замысла, не потратив время и деньги на техническую реализацию. Как бы странно не звучало, даже в таких ситуация очень сильно возрастает доверие между участниками проекта. Одним из результатов воркшопа будет являться документ, описывающий нефункциональные требования к разрабатываемой системе. Резонный вопрос — надо ли это делать и дорого ли это? Отвечаем: это стоит 2 дня плотной работы организованной команды. Большинство ошибок при разработке продукта, если этого не сделать, будут стоить намного дороже.
Необходимо отметить, что даже проведенный воркшоп не гарантирует правильности и полноты полученных данных. С течением времени бизнес-идея может измениться из-за внешних обстоятельств. К примеру, сейчас происходят очень большие изменения в структуре работы практически любого бизнеса. Мы точно знаем, что мир через пару месяцев будет уже не такой, как раньше (привет, COVID-19 и карантин!). В этом случае при разработке системы можно использовать хорошие практики в виде шаблона CQRS на уровне архитектуры приложения и с большой долей вероятности это позволит заново использовать написанную функциональность за счет разделения на независимые компоненты.
Что сделали мы
В одном из проектов по управлению и автоматизации бизнес-процессов компании с флотом морских судов перед нами стояла задача в минимальные сроки и с минимальным затратами выпустить первую версию ПО. Был выбран подход внедрения CQRS на уровне логической архитектуры.
Само приложение имело следующую схему архитектуры:
Как видно из схемы, если соблюдать базовые принципы SOLID, а именно Dependency Inversion и Dependency Injection, то при хорошей настройке контейнеров инверсии управления все команды и запросы становятся небольшими кусочками, которые очень легко начать переиспользовать в разных частях вашей системы. Так и было в этом случае, что дало свой положительный результат.
В данном случае видно 3 части системы, которые вполне могут иметь схожую работу с Моделью:
Было замечено, что люди, которые используют приложение в офисе, намного чаще читают данные с кораблей, нежелие заполняют. При этом люди, которые находятся в Offline- зоне на кораблях, наоборот больше записывают в приложение данные, чем читают. Зачем это нужно знать? Затем, что пока это лишь заготовки под масштабирование архитектуры, которые конечно уже принесли свою пользу, но могут принести гораздо больше пользы в следующих этапах развития архитектуры. При желании выделить окружающие контексты из кусочков запросов в одни физические сервисы с оптимизированной базой данных под чтение будет намного легче, а контексты из команд — в другие сервисы. Всё это уже будет зависеть от бизнес-задач и от направлений развития архитектуры.
Примеры того, как внедрить такое разбиение у себя в проекте
Ниже я привожу пару основных классов на языке C#, которые можно просто переиспользовать в своих решениях.
Пример Биндинга запросов через Ninject
После инъекции IHandlerFactory в ваш класс вы получаете возможность использовать свои команды и запросы следующим образом:
Пример выполнения запроса:
Пример выполнения команды:
Когда я только начал пользоваться этими наработками, мысли были такие:
Но конечно всё надо применять ситуативно и с умом. Для этого и нужно разработать архитектуру. Другой момент что не надо её пытаться придумать на 300 шагов вперёд. Она должна ситуативно развиваться вместе с продуктом, и быть всем ответом минимум на 3 вопроса:
Также очень важным этапом является момент выделения Bounded Context в системе. Данная практика хорошо помогает изобразить структуру бизнеса заказчика, найти с ним общий язык и управлять регрессией в продукте. Но об этом уже следующая статья.
Преимущества CQRS на уровне логической архитектуры
Базовая архитектура рассмотренного приложения была выстроена с соблюдением разных принципов и шаблонов проектирования: MVVM, SOLID, CQRS и т.д. Это позволило переиспользовать функциональность фич для разных клиентов приложения. При этом, внедрение не занимало много времени и было достаточно недорогим.
Реализация данного подхода не потребовала дополнительных затрат, так как при старте разработки у команды были уже наработанные классы и один уровень понимания архитектуры приложения. В последующих доработках этот подход полностью себя оправдал: большой процент функциональности можно было просто гибко переиспользовать. При таком подходе заказчик существенно сократил затраты на реализацию функций, определённые части которых дублируются для разных клиентов приложения.
Напоследок
Ошибочно Agile-подход к разработке трактуется как “не надо ничего проектировать заранее, надо ввязаться в бой, а там война — план покажет”. А если нам будет не хватать скорости работы или скорости изменения программы, мы зарядим серебряную пулю — микросервисы. Ведь на всех конференциях рассказывают, что микросервисы — это просто и решает сразу все проблемы. Такой оптимизм, как правило, ведет к потере денег и неработающему продукту.
С другой стороны, проектировать все заранее в нашем быстро меняющемся мире практически невозможно. Как всегда надо находить баланс. Во-первых, проработка архитектуры решения позволяет осознанно выбрать подходящее решение на текущем этапе и в итоге сэкономить денег заказчику. Во-вторых, документирование принятых архитектурных решений позволит в дальнейшем понять, почему именно такие решения были приняты. В-третьих, периодическая валидация изменившихся условий позволяет снизить риски отказов в работе решения и принять взвешенное решение о необходимости доработки или изменения. Таким образом, следование грамотным практикам непосредственно при написании кода позволяет получить хороший фундамент, на основании которого можно будет масштабировать решение в дальнейшем.