MACH とは何か、誰が定義したのか

マッハ によって造られた略語です MACHアライアンス、協会 commercetools、Contentful、EPAM Systems などによって 2020 年に設立されたテクノロジー ベンダーのグループ。そうではない それは製品であり、システムを構築するための一連のアーキテクチャ原則です。 現代の企業。

  • M — マイクロサービス: 各ビジネス機能は独立したサービスです
  • A — API ファースト: 各サービスは、明確に定義された API をプライマリ インターフェイスとして公開します。
  • C — クラウドネイティブ: パブリック クラウド向けに構築され、柔軟なスケーリングとマネージド サービスを備えています
  • H — ヘッドレス: フロントエンドとバックエンドが分離されています

基本的な考え方は、 最高の品種: 単一のスイートを購入する代わりに 何でもできる（平凡）機能ごとに最適なサービスを選んでプラットフォームを構成 オーダーメイド。製品の最高の検索エンジン (Algolia)、最高のチェックアウト (Stripe)、 最高の CMS (コンテンツフル)、最高の PIM (Akeneo)。

4 つの MACH ディメンションの詳細

マイクロサービス: 境界付きコンテキストの分解

MACH アーキテクチャでは、コマース ドメインは調整された独立したサービスに分解されます。 あい 境界のあるコンテキスト ドメイン駆動設計の: 

// 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 ファースト: 実装前の契約

API ファーストのシステムでは、API は定義されたコントラクトです。 前に 実装の。 契約を締結しているため、各チームが独立して独自のサービスを開発できます。 APIはすでに定義されています。 

// 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'

クラウドネイティブ: 柔軟なスケーリングとマネージド サービス

クラウドネイティブとは「クラウド上で実行する」という意味ではなく、悪用するために特別に設計されたことを意味します。 クラウド機能: 自動水平スケーリング、耐障害性、可観測性 統合:

  • Kubernetes によってオーケストレーションされた Docker コンテナ (またはイベント駆動型ロードの場合は Lambda Functions)
  • セルフマネージド インスタンスの代わりにマネージド データベース (Cloud Spanner、RDS、DynamoDB)
  • 非同期通信用のイベントバス管理 (AWS EventBridge、Google Pub/Sub)
  • フロントエンド配信用のグローバル CDN
  • 自動サーキットブレーカーと復元力のための再試行

ヘッドレス: バックエンドから解放されたフロントエンド

MACH の H 次元については、シリーズの最初の記事ですでに検討しました。 フロントエンドは API を消費しますが、バックエンドによって生成されるわけではありません。 MACH アーキテクチャではこれが完了します 多くの場合、 BFF (フロントエンド用バックエンド) API を i 向けに最適化する 特定のクライアント: 

// 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: 本当の比較

MACH vs Monolith: どちらが良い場合

  • モノリス管理 (Shopify、WooCommerce): 数週間で市場投入、小規模チーム、低コスト - GMV < 500 万ユーロ/年に最適
  • 部分的な MACH (ヘッドレス + ベストオブブリード): 段階的な柔軟性、中規模のチーム — 特定のニーズがある年間 GMV 5 ～ 5000 万ユーロに最適
  • フルマッハ: 最大限の柔軟性、高コスト、大規模なチーム — GMV > 5,000 万ユーロ/年、または特定の企業要件に適しています

MACH ガバナンスとアンチパターン

MACH 実装で最もよくある間違いは、ガバナンスなしで断片化しすぎることです。

避けるべき MACH アンチパターン

  • 時期尚早のマイクロサービス：1000個扱うと20個のサービスに分解 月あたりの注文数は純粋にオーバーエンジニアリングです。モジュラーモノリスから始めて、分解するだけ スケールが異なる部分。
  • バージョン管理された API コントラクトがない: API のバージョン管理がなければ、すべてのチームが 展開時に他のものを破壊する可能性があります。 OpenAPI 3.1 + セマンティック バージョニングを採用します。
  • カスケードされた同期呼び出し：5つのサービスを連続して呼び出すリクエスト 遅延が蓄積されます。可能であれば並列呼び出しを使用し、大量の読み取りには CQRS パターンを使用します。
  • 共有データベース: 2 つの MACH サービスがデータベースを共有する場合、それらは共有されません。 本当に独立した。各サービスには独自のデータストアが必要です。

MACH を段階的に実装する

一度に MACH に移行する必要はありません。ストラングラーフィグパターンアプローチ それをお勧めします:

  1. フェーズ 1: 既存のモノリスの上にヘッドレス レイヤーを追加します。フロントエンド 新しい呼び出し API では、モノリスが REST/GraphQL レイヤー経由で API を生成します。コアに変更はありません。
  2. フェーズ2: 最もニーズが高い機能の最初のマイクロサービスをプルします 仕様 (多くの場合: 検索またはインベントリ)。モノリスは引き続き残りを処理します。
  3. フェーズ 3: サービスごとに抽出サービスを継続し、徐々に削除します モノリスへの依存。

結論

MACH はチェックリストではなく、アーキテクチャ上の願望です。 API ファーストとヘッドレスの原則 部分的な実装であっても真の価値をもたらします。マイクロサービスへの分解と クラウドネイティブは全体像を完成させますが、組織の成熟度が必要です。

次の記事では、具体的な実装について説明します: Shopify Hydrogen マネージド インフラストラクチャ上のヘッドレス、セルフホスト型オープンソースを好む人向けの Medusa.js、 ネイティブ GraphQL ニーズを持つ Python チーム向けの Saleor。

前の記事 ← ヘッドレスコマース: それは何ですか
シリーズの次は Shopify 水素と酸素 →