Co je MACH a kdo jej definoval

MACH je zkratka, kterou vytvořil Aliance MACH, sdružení of technology vendors founded in 2020 by commercetools, Contentful, EPAM Systems and others. Ne it is a product — it is a set of architectural principles for building systems moderní podnik.

  • M — Mikroslužby: každá obchodní funkce je nezávislou službou
  • A — API-first: Každá služba odhaluje dobře definovaná API jako své primární rozhraní
  • C — Cloud-native: Vytvořeno pro veřejný cloud, s elastickým škálováním a spravovanými službami
  • H — Headless: frontend a backend jsou odděleny

Základní myšlenkou je nejlepší z plemene: místo nákupu jednoho apartmánu která dělá všechno (průměrná), vyberte nejlepší službu pro každou funkci a vytvořte platformu na míru. Nejlepší vyhledávač produktů (Algolia), nejlepší pokladna (Stripe), nejlepší CMS (Contentful), nejlepší PIM (Akeneo).

Čtyři MACH rozměry v detailu

Mikroslužby: Dekompozice pro ohraničený kontext

V architektuře MACH je obchodní doména rozložena na zarovnané nezávislé služby ai ohraničený kontext design řízený doménou: 

// Esempio di decomposizione in microservizi commerce

const MACH_SERVICES = {
  // Servizi core commerce
  catalog: 'Gestione prodotti, categorie, attributi, varianti',
  pricing: 'Regole di prezzo, sconti, tier pricing, valute',
  inventory: 'Stock real-time, warehouse, backorder',
  cart: 'Sessioni di carrello, regole di promozione',
  checkout: 'Checkout flow, address validation, ordine',
  payments: 'Processing pagamenti, rimborsi, split payments',
  fulfillment: 'Gestione spedizioni, tracking, resi',

  // Servizi supporto
  search: 'Full-text search, filtri, ranking (Algolia)',
  recommendations: 'Prodotti correlati, personalization',
  cms: 'Contenuto editoriale, landing page (Contentful/Sanity)',
  pim: 'Product Information Management (Akeneo)',
  loyalty: 'Punti, rewards, programmi fedeltà',
  notifications: 'Email, SMS, push notifications',
};

API-First: Smlouva před implementací

V systému API-first je API smlouva, která je definována Před implementace. Každý tým může vyvinout svou vlastní službu nezávisle na smlouvě API je již definováno. 

// OpenAPI spec per il Catalog Service
openapi: 3.1.0
info:
  title: Catalog Service API
  version: 2.0.0

paths:
  /products:
    get:
      summary: Lista prodotti con paginazione e filtri
      parameters:
        - name: cursor
          in: query
          schema:
            type: string
        - name: category
          in: query
          schema:
            type: string
        - name: priceMin
          in: query
          schema:
            type: number
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProductPage'

  /products/{id}:
    get:
      summary: Dettaglio prodotto singolo
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
        '404':
          $ref: '#/components/responses/NotFound'

Cloud-Native: Elastické škálování a spravované služby

Cloud-native neznamená „běží v cloudu“ – znamená to, že je navrženo speciálně k využívání možnosti cloudu: automatické horizontální škálování, odolnost proti chybám, pozorovatelnost integrovaný:

  • Docker kontejnery organizované Kubernetes (nebo funkcemi Lambda pro načtení řízená událostmi)
  • Spravované databáze (Cloud Spanner, RDS, DynamoDB) namísto samostatně spravovaných instancí
  • Spravováno sběrnicí událostí (AWS EventBridge, Google Pub/Sub) pro asynchronní komunikaci
  • Globální CDN pro frontend doručení
  • Automatický jistič a opakování pro odolnost

Headless: Frontend Free from Backend

Rozměr H MACH již byl prozkoumán v prvním článku série: the frontend spotřebovává API, není generováno backendem. In un'architettura MACH completa questo často znamená a BFF (Backend pro frontend) k optimalizaci API pro i konkrétní klienti: 

// BFF Pattern: GraphQL aggregation layer
// Aggrega chiamate a più microservizi in un'unica risposta ottimizzata

type Query {
  productPage(
    category: String
    cursor: String
    filters: [FilterInput!]
  ): ProductPageResult!
}

type ProductPageResult {
  products: [ProductSummary!]!
  facets: [FacetGroup!]!       # da Algolia
  recommendations: [ProductSummary!]!  # da recommendation service
  pageInfo: PageInfo!
}

// Il resolver fa chiamate parallele a catalog, search e recommendations
const resolvers = {
  Query: {
    productPage: async (_, args) => {
      const [products, facets, recs] = await Promise.all([
        catalogService.getProducts(args),
        searchService.getFacets(args),
        recommendationService.get(args.category),
      ]);
      return { products, facets, recommendations: recs, pageInfo: products.pageInfo };
    },
  },
};

MACH vs Monolith: Skutečné srovnání

MACH vs Monolith: Když je to lepší co

  • Spravováno Monolith (Shopify, WooCommerce): doba uvedení na trh v týdnech, malý tým, nízké náklady — ideální pro GMV < 5 mil. EUR/rok
  • Částečný MACH (bezhlavý + nejlepší z plemene): postupná flexibilita, střední tým — ideální pro GMV 5-50 mil. EUR/rok se specifickými potřebami
  • Plný MACH: maximální flexibilita, vysoké náklady, velký tým – opodstatněné pro GMV > 50 mil. EUR/rok nebo specifické podnikové požadavky

MACH Governance a Anti-pattern

Nejčastější chybou v implementacích MACH je přílišná fragmentace bez správy:

MACH Anti-pattern, kterému je třeba se vyhnout

  • Předčasné mikroslužby: Při manipulaci s 1000 se rozloží na 20 služeb objednávky/měsíc je čistý přetechnizovaný. Začněte s modulárním monolitem, stačí se rozložit části, které se různě měří.
  • Žádné verzované smlouvy API: Bez verzování API, každý tým rozbije ostatní v nasazení. Přijměte OpenAPI 3.1 + sémantické verzování.
  • Kaskádové synchronní hovory: Požadavek, který volá 5 služeb za sebou akumulovat latenci. Kde je to možné, používejte paralelní volání, vzor CQRS pro náročné čtení.
  • Sdílená databáze: Pokud dvě služby MACH sdílejí databázi, nejsou skutečně nezávislý. Každá služba musí mít vlastní datové úložiště.

Implementujte MACH postupně

Nemusíte migrovat na MACH všechny najednou. Přibližuje se vzor fíku škrtiče doporučuje se:

  1. Fáze 1: Přidejte vrstvu bez hlavy na stávající monolit. Frontend nové volání API, monolit generuje API přes vrstvu REST/GraphQL. Žádné změny v jádru.
  2. Fáze 2: Vytáhněte první mikroslužbu pro funkci s největšími potřebami specifikace (často: vyhledávání nebo inventarizace). Monolit se nadále stará o zbytek.
  3. Fáze 3: Pokračujte v extrakčním servisu po servisu, odstraňovejte postupně závislost na monolitu.

Závěry

MACH je architektonická aspirace, nikoli kontrolní seznam. Principy API-first a headless přinášejí skutečnou hodnotu i v dílčích implementacích. Rozklad na mikroslužby a cloud-native doplní obrázek, ale vyžaduje organizační vyspělost.

V dalších článcích prozkoumáme konkrétní implementace: Shopify Hydrogen pro ty, kteří chtějí bezhlavě na spravované infrastruktuře, Medusa.js pro ty, kteří preferují self-hosted open-source, např Prodej pro týmy Python s nativními potřebami GraphQL.

Předchozí článek ← Bezhlavý obchod: Co to je
Další v řadě Shopify Vodík a kyslík →