Що таке MACH?

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 йде врозріз з модерновою парадигмою, коли після першого спринту вже потрібно віддавати продукт на апробацію для отримання зворотного зв'язку.

Якщо узагальнити, то ці обмеження та примуси забирають швидкість.

Отправить комментарий

Добавлять новые комментарии запрещено.*

Новые Старые