Domain-Driven Architecture #

Seiring bertambahnya kompleksitas sistem software—terutama pada sistem bisnis berskala menengah hingga besar—tantangan utama bukan lagi soal teknologi, melainkan soal pemahaman domain bisnis. Banyak sistem gagal bukan karena kodenya jelek, tetapi karena arsitekturnya tidak mampu merepresentasikan realitas bisnis yang terus berkembang.

Di sinilah Domain-Driven Architecture (DDA) berperan. DDA menempatkan domain bisnis sebagai pusat dari arsitektur aplikasi, bukan database, framework, atau infrastruktur.

Berikut gambaran arsitektur Domain-Driven secara text-based:

+---------------------------+
|        Presentation       |
|  (API, UI, Controller)    |
+-------------+-------------+
              |
              v
+---------------------------+
|        Application        |
| (Use Case / Orchestration)|
+-------------+-------------+
              |
              v
+---------------------------+
|          Domain           |
|  - Entity                 |
|  - Value Object           |
|  - Aggregate              |
|  - Domain Service         |
|  - Domain Event           |
+-------------+-------------+
              |
              v
+---------------------------+
|       Infrastructure      |
| (DB, Message Broker, API) |
+---------------------------+

Lapisan Domain berada di tengah dan menjadi inti dari sistem. Lapisan lain bergantung pada domain, bukan sebaliknya.

Apa itu Domain-Driven Architecture? #

Domain-Driven Architecture adalah pendekatan arsitektur yang berasal dari prinsip Domain-Driven Design (DDD), di mana struktur aplikasi dirancang berdasarkan:

• Model bisnis yang nyata
• Bahasa yang sama antara developer dan stakeholder (Ubiquitous Language)
• Pemisahan tanggung jawab yang jelas antar lapisan

DDA menekankan bahwa:

Business rules adalah aset paling berharga dari sebuah aplikasi.

Oleh karena itu, business rules harus:

• Terisolasi
• Mudah diuji
• Tidak tercemar detail teknis

Tujuan Architecture #

Tujuan utama DDA adalah:

1. Merepresentasikan kompleksitas bisnis dengan akurat
2. Mengurangi ketergantungan domain terhadap teknologi
3. Meningkatkan maintainability jangka panjang
4. Memudahkan kolaborasi developer dan stakeholder bisnis
5. Mencegah anemic domain model (logic bisnis tercecer di service atau controller)

Dengan DDA, perubahan aturan bisnis tidak selalu berarti refactor besar-besaran di seluruh sistem.

Kapan Cocok Digunakan? #

DDA sangat cocok jika:

• Sistem memiliki aturan bisnis kompleks
• Banyak istilah bisnis spesifik
• Aplikasi berskala menengah hingga besar
• Tim terdiri dari banyak developer
• Domain berkembang dan sering berubah

Contoh use case:

• Fintech
• E-commerce besar
• ERP / CRM
• Health system
• Logistics & supply chain

Tidak direkomendasikan jika: #

• Aplikasi CRUD sederhana
• MVP dengan scope sangat kecil
• Tim belum familiar dengan konsep DDD
• Waktu pengembangan sangat singkat

Pros dan Cons #

✅ Pros #

1. Business logic terpusat dan konsisten
2. Kode lebih mudah dipahami secara konseptual
3. High testability (domain bisa dites tanpa DB)
4. Scalable secara arsitektural
5. Lebih tahan terhadap perubahan teknologi

❌ Cons #

1. Learning curve tinggi
2. Boilerplate lebih banyak di awal
3. Overkill untuk aplikasi sederhana
4. Butuh disiplin tim yang kuat
5. Salah implementasi bisa jadi “DDD palsu”

Insight Tambahan yang Penting #

• DDA ≠ Monolith → sangat cocok dikombinasikan dengan Microservices
• Bounded Context adalah kunci untuk menghindari Big Ball of Mud
• Event-driven architecture sangat natural jika domain sudah matang
• DDA bersinar dalam jangka panjang, bukan short-term

Best Practice #

1. Jadikan Domain Benar-Benar Independen #

• Domain tidak boleh bergantung ke:

  • Database
  • Framework
  • HTTP / gRPC

Domain harus murni berisi aturan bisnis.

2. Gunakan Ubiquitous Language #

• Nama class, method, dan variable harus:

  • Selaras dengan bahasa bisnis
  • Disepakati bersama stakeholder

Contoh buruk:

• ProcessData()

Contoh baik:

• ApproveLoan()

3. Pisahkan Entity dan Value Object #

• Entity: punya identity (ID)
• Value Object: immutable, dibandingkan berdasarkan nilai

Ini membantu mencegah logic bocor ke luar domain.

4. Gunakan Aggregate untuk Konsistensi #

• Semua perubahan state harus lewat Aggregate Root
• Jangan akses entity internal aggregate secara langsung

Tujuan: menjaga invariant bisnis tetap valid.

5. Jangan Takut Dengan Domain Service #

Jika logic:

• Tidak cocok di entity
• Melibatkan banyak aggregate

Gunakan Domain Service, bukan Application Service.

6. Infrastruktur Selalu di Pinggir #

• Repository adalah abstraction, bukan implementasi
• Implementasi DB ada di infrastructure

Domain hanya mengenal interface.

Penutup #

Domain-Driven Architecture bukan tentang membuat sistem menjadi rumit, tetapi tentang mengelola kompleksitas dengan benar.

Jika bisnis Anda kompleks, terus berkembang, dan bernilai tinggi—maka menempatkan domain sebagai pusat arsitektur adalah investasi yang sangat masuk akal.

DDA mungkin terasa berat di awal, tetapi ia membayar dirinya sendiri melalui:

• Kode yang lebih sehat
• Tim yang lebih sinkron
• Sistem yang lebih tahan lama

Good architecture hides complexity. Great architecture understands it.