MACH is yefa for Microservices-based, API-first, Cloud-native, and Headless principles for designing software applications.
MACH — это группа архитектурных принципов, которые при применении вместе обеспечивают построение системы, отвечающей современным требованиям к программному продукту.
Что же это за требования такие? Ну, можно накопить стандарты *-ilty (maintainability, scalability, deployability, saleability), но все сводится к обычному «чтобы было легче, а не сложнее».
Расшифровываем принципы
Пока все эти принципы давно известны и даже немного странно их описывать, потому что это очевидно как день, но может какому-то джуну это будет полезно.
Microservices-based – нет, не нужно все сразу писать на нано микро-сервисах, просто нужно проектировать систему так, чтобы бизнеслогика была отделена друг от друга, насколько это возможно (Aggregations form DDD). Писать код, пытаясь сделать гипотетическое обособление этого функционала в независимый сервис более легким и с меньшим влиянием на общий продукт.
API-first — функционал, открытый для использования через публичные контракты, которые утверждаются до начала разработки, и меняются только после тщательного обдумывания. Потому что, когда понимаешь, чего ожидают, реализуется это легче.
Cloud-native — не забывать об акрониме IaC и пользоваться железом от Andy Jassy\Sundar Pichai\Satya Nadella на выбор. И желательно не просто железом, а интегрироваться со всем доступным количеством сервисов и автоматизировать все доступные процессы. Согласитесь, когда все автоматизировано, даже деплой становится проще нажатия одной кнопки merge.
Headless — стараться не привязываться к фреймвокам (фреймворки меняются, а for-циклы навсегда). О построении бэкенда агностического к фронтенду это и так ясно. Но если экспрессовский req-res не протекает в контроллере, то заменить его на фастифай будет легче.
Итак, что дает нам выполнение всех принципов MACH?
Гибкое, но без хаоса в контрактах решение. Когда продакт-овнер утверждает изменение в контракте, а бизнес-логика разделена и концентрирована, можно забыть о хаотичных скрипах и эстимейти овер 9000 для придания одной фичи.
Когда едешь на облаке, трудно увязнуть в болоте старых технологий. Cloud-провайдер сам побуждает пользоваться их новыми сервисами и не костянеть в технологиях, при этом хайрить разработчиков будет легче.
Скейлите микро-сервисы в облаке, это далеко не то же, что отменить 10 ящиков за балансировщиком.
Если фреймворк – это плагин, то сообщение об остановке его поддержки не приведет к облысению техлида.
Автономная бизнес-логика с автоматическими деплоями сделает счастливым любого скрам-мастера, спринты крутятся и функционал релизится.
Может MACH что-то уносит?
Как любой свод правил он ограничивает и заставляет.
Как минимум, он заставляет думать каждый раз, как комитиш или не нарушается какое-либо из правил. А вынуждение лишний раз подумать – это уже хороший повод не пользоваться им.
Headless-принцип ограничивает архитектуру, принуждает строить дополнительные механизмы обеспечения границ меж функционалом (абстракции, DTO etc). А любые усилия, потраченные не на реализацию бизнес логики, бесполезны в глазах продакт-овнера (и не только).
Api-first – меняет процессы разработки, заставляет нетехнический персонал согласовывать контракты API, запрещает девелоперу добавить какое-либо нужное ему свойство к респонcу.
Глубокая интеграция с клаудом требует времени и усилий на овладение сервисами, знания целесообразны только для конкретного провайдера и не нужны для другого.
Существенные инвестиции на старте в построение автоматизированной инфраструктуры CI\CD еще до начала построения MVP идет вразрез с модерновой парадигмой, когда после первого спринта уже нужно отдавать продукт на апробацию для получения обратной связи.
Если обобщить, то эти ограничения и принуждения забирают скорость.