Microservices, Antara Ukuran Kecil dan Kompleksitas Besar

Beberapa tahun terakhir, kata microservices seolah menjadi mantra sakti di dunia teknologi. Banyak perusahaan beralih dari monolit ke microservices dengan harapan semua masalah skala, performa, dan kolaborasi akan terselesaikan.

Namun, kenyataannya sering jauh dari harapan: setelah dipecah menjadi banyak service, tim justru kebingungan mengelola dependensi, data tersebar, dan komunikasi antar sistem menjadi mimpi buruk.

Vlad Khononov menyebut fenomena ini dengan sangat tepat:

“Microservices are not the destination — they are the outcome of understanding your domain.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Dengan kata lain, microservices bukan tujuan, melainkan konsekuensi logis dari penerapan DDD yang baik.

Microservices dan Janji Kemerdekaan

Secara konsep, microservice architecture adalah tentang memecah sistem besar menjadi unit-unit kecil yang dapat dikembangkan, dirilis, dan diskalakan secara independen.

Setiap microservice:

• Menangani satu fungsi bisnis tertentu,

• Memiliki data sendiri,

• Dan bisa dikelola oleh satu tim otonom.

Tujuannya terdengar sederhana: independence and scalability. Namun dalam praktiknya, banyak organisasi gagal karena tidak memahami batas domain sebelum membagi service.

“Without understanding domain boundaries, splitting a monolith creates distributed chaos, not distributed systems.” — Khononov, 2022

Dan di situlah peran DDD menjadi sangat penting.

Hubungan DDD dan Microservices

DDD memberi fondasi berpikir yang kuat untuk menentukan batas alami dari setiap microservice, yaitu melalui konsep bounded context.

• DDD Concept: Bounded Context

  • Padanan Microservices: Microservice Boundary

  • Tujuan: Memisahkan logikadan model bisnis secara mandiri

• DDD Concept: Ubiquitous Language

  • Padanan Microservices: Service API Contract

  • Tujuan: Bahasa dan istilah konsisten dalam satu tim

• DDD Concept: Context Map

  • Padanan Microservices: Service Interaction Diagram

  • Tujuan: Hubungan antar service dan pola komunikasinya

• DDD Concept: Communication Pattern

  • Padanan Microservices: API/Event Integration

  • Tujuan: Cara service berkoordinasi tanpa coupling

Jadi, bounded context dalam DDD bukan sekadar konsep abstrak, ia adalah peta alami yang membantu kita menentukan microservice yang sehat.

Bounded Context Sebagai Panduan Desain Microservice

Banyak kegagalan microservice berasal dari salah memotong sistem: dibagi berdasarkan lapisan teknis (UI, backend, database), bukan area bisnis.

Hasilnya: service terlalu kecil, saling bergantung, dan kehilangan makna bisnis.

DDD membantu memotong sistem secara semantik, bukan struktural.

Contoh: Daripada membagi berdasarkan teknologi:

/user-api
/payment-service
/database-service

DDD akan mendorong pembagian berdasarkan domain:

/billing-context
/inventory-context
/customer-context

Setiap context punya logika, data, dan bahasa sendiri, itulah microservice yang benar-benar “domain-driven”.

Integrasi Antar Microservice: Komunikasi Antara Context

Ketika kita punya banyak bounded context (atau microservice), komunikasi di antaranya harus dikelola dengan hati-hati.

DDD memperkenalkan communication patterns yang juga relevan di dunia microservices, seperti:

• Customer–Supplier

• Conformist

• Partnership

• Separate Ways

Dalam konteks arsitektur terdistribusi, pola-pola ini bisa diterjemahkan sebagai:

• Customer–Supplier → satu service tergantung API dari service lain,

• Conformist → mengikuti format upstream tanpa perubahan,

• Partnership → dua tim berkolaborasi erat,

• Separate Ways → berjalan mandiri tanpa integrasi real-time.

Misalnya:

// Contoh komunikasi event-driven antar microservice
#[derive(serde::Serialize, serde::Deserialize)]
struct OrderPlaced {
    order_id: u64,
    total: f64,
}

fn publish_order_placed(order: OrderPlaced) {
    // publish ke message broker (Kafka, NATS, dll)
    println!("Publishing event: {:?}", order);
}

Pendekatan event-driven ini menjaga agar microservice tetap otonom, karena setiap service bereaksi terhadap event, bukan memanggil service lain secara langsung.

Tantangan Microservice di Dunia Nyata

Meski konsepnya indah, arsitektur microservices membawa kompleksitas baru.

Khononov mengingatkan, bahwa:

“Microservices move complexity from code to communication.” — Vlad Khononov, 2022

Mari lihat beberapa jebakan umum yang sering terjadi:

1. Over-segmentation (Service Terlalu Kecil)

Engineer terlalu semangat memecah sistem hingga setiap fungsi menjadi satu service. Akibatnya, integrasi menjadi rumit dan deployment berantakan.

Solusi: Pastikan setiap service punya makna domain utuh (bounded context lengkap), bukan sekadar endpoint CRUD.

2. Shared Database

Beberapa service masih berbagi database yang sama, ini menghapus batas konteks.

Solusi: Setiap service memiliki database sendiri, bahkan jika data yang disimpan mirip. Gunakan event untuk sinkronisasi, bukan query silang.

3. Communication Hell

Service saling memanggil API secara berantai (A → B → C → D). Jika satu mati, semuanya ikut gagal.

Solusi: Gunakan asynchronous messaging (event-driven) untuk mengurangi coupling antar service.

4. Terlalu Banyak Infrastruktur

Microservice memerlukan CI/CD pipeline, monitoring, logging, service mesh, dan sebagainya. Untuk tim kecil, overhead ini bisa lebih mahal daripada manfaatnya.

Solusi: Mulai dari modular monolith, struktur monolit yang sudah terpisah per context. Jika sudah stabil, baru evolusikan ke microservice sejati.

Modular Monolith Sebagai Titik Awal

Khononov menyarankan pendekatan yang realistis:

“Start with a modular monolith. Split it when you must, not when you can.” — Khononov, 2022

Artinya, kamu bisa mulai dengan sistem monolit tunggal, tapi struktur internalnya sudah mengikuti prinsip bounded context.

Contoh struktur folder dalam Rust:

src/
 ├── billing/
 │    ├── domain.rs
 │    ├── service.rs
 │    └── repository.rs
 ├── inventory/
 │    ├── domain.rs
 │    └── service.rs
 └── main.rs

Ketika skala sistem tumbuh, tiap folder domain ini bisa dengan mudah dipecah menjadi microservice independen, karena sejak awal, batas context-nya sudah jelas.

DDD sebagai Landasan Microservice Sehat

Inti dari pesan Khononov sangat sederhana tapi krusial:

“Without DDD, microservices are just distributed monoliths.” — Vlad Khononov (2022)

DDD membantu kita:

1. Menentukan batas yang sehat (bounded contexts),

2. Menjaga otonomi antar tim,

3. Mencegah duplikasi logika bisnis,

4. Menghindari coupling antar service.

Dengan kata lain, DDD adalah kompas yang menunjukkan di mana memotong sistem. Microservices hanyalah hasil fisik dari pemotongan itu.

Ringkasnya, Microservices yang Bermakna

Microservices bukan soal ukuran kecil, tapi soal batas makna yang jelas. Sebuah microservice seharusnya mencerminkan satu domain bisnis yang utuh, bukan sekadar satu tabel di database atau satu endpoint di API gateway.

DDD membantu kita menemukan batas itu, bukan lewat intuisi arsitek, tapi lewat percakapan lintas tim, pemahaman domain, dan bahasa umum yang disepakati.

“Good microservices emerge from good domain models.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.