MACH is yefa for M icroservices-based, A PI-first, C loud-native, and H eadless 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у.
Глибока інтеграція з клаудом вимагає часу та зусиль на оволодіння сервісами, знання є доцільними тільки для конкретного провайдера і не потрібні для іншого.
Суттєві інвестиції на старті у побудову автоматизованої інфраструктури CICD ще до початку побудови MVP йде врозріз з модерновою парадигмою, коли після першого спринту вже потрібно віддавати продукт на апробацію для отримання зворотного зв'язку.
Якщо узагальнити, то ці обмеження та примуси забирають швидкість.