Banyak perusahaan memulai pembangunan aplikasi enterprise dengan pertanyaan yang salah.
“Pakai Java atau Node.js?”
“Microservices atau Monolith?”
“Database-nya PostgreSQL atau MySQL?”
“Deployment-nya Kubernetes atau cloud?”
Semua pertanyaan tersebut valid. Tetapi ada satu pertanyaan yang seharusnya muncul lebih awal:
Masalah bisnis apa sebenarnya yang ingin diselesaikan?
Inilah titik yang sering terlewat. Tim teknologi terlalu cepat masuk ke architecture, framework, database, bahkan coding, sementara proses bisnis, business requirement, dan batas domain belum benar-benar dipahami.
Akibatnya bukan selalu aplikasi yang gagal secara teknis. Justru sering terjadi sebaliknya: kodenya rapi, architecture-nya modern, infrastrukturnya scalable, tetapi sistem yang dibangun tidak sepenuhnya menjawab kebutuhan bisnis.
Untuk aplikasi enterprise, masalah semacam ini menjadi mahal.
Semakin besar organisasi, semakin banyak stakeholder, semakin kompleks integrasi, dan semakin panjang umur sistem, semakin besar pula dampak dari keputusan yang salah di awal.
Karena itu, prinsip yang sederhana tetapi penting adalah:
Jangan mulai dari coding. Mulai dari bisnis.
Mengapa Coding Bukan Langkah Pertama?
Dalam proyek software enterprise, feature list sering dianggap sebagai requirement.
“Buat dashboard.”
“Buat approval.”
“Buat aplikasi mobile.”
“Integrasikan dengan ERP.”
Padahal feature bukan business requirement.
Misalnya, sebuah perusahaan mengatakan membutuhkan dashboard. Pertanyaan berikutnya bukan langsung “dashboard menggunakan framework apa?”, melainkan:
- Siapa yang menggunakan dashboard tersebut?
- Keputusan apa yang harus dibuat berdasarkan informasi di dalamnya?
- Data mana yang benar-benar dibutuhkan?
- Seberapa cepat data harus tersedia?
- Apa dampaknya jika informasinya terlambat atau salah?
Pertanyaan-pertanyaan tersebut membantu mengubah permintaan fitur menjadi konteks bisnis yang dapat diterjemahkan secara tepat ke dalam sistem.
Business requirement seharusnya menjelaskan outcome yang ingin dicapai. Functional requirement kemudian menjelaskan kemampuan sistem untuk mencapai outcome tersebut.
Contohnya:
Business Requirement
Mempercepat proses approval procurement dari rata-rata lima hari menjadi maksimal dua hari.
Functional Requirement
Sistem menyediakan workflow approval bertingkat berdasarkan nilai transaksi dan kewenangan pengguna.
Technology Implementation
Barulah tim menentukan bagaimana workflow, API, database, authentication, dan infrastructure akan dibangun.
Perbedaannya terlihat sederhana, tetapi dampaknya besar.
Tanpa lapisan pertama, tim membangun fitur. Dengan lapisan pertama, tim membangun hasil.
Mulai dari Business Requirement
Sebelum membahas system architecture, setidaknya ada beberapa pertanyaan mendasar yang harus dijawab.
- Apa masalah bisnis yang ingin diselesaikan?
- Siapa stakeholder yang terdampak?
- Proses bisnis mana yang akan berubah?
- Bagaimana keberhasilan sistem akan diukur?
- Dan yang sering dilupakan: apa yang tidak termasuk dalam scope?
Pertanyaan terakhir sangat penting dalam aplikasi enterprise.
Tanpa batas yang jelas, hampir semua kebutuhan organisasi dapat masuk ke dalam sistem. Sales memiliki kebutuhan sendiri. Finance memiliki kebutuhan sendiri. Warehouse memiliki kebutuhan sendiri. Management memiliki dashboard sendiri.
Semua terlihat penting.
Semua akhirnya ingin dimasukkan.
Di titik tersebut, aplikasi mulai berkembang bukan berdasarkan business priority, melainkan berdasarkan akumulasi permintaan.
Inilah salah satu alasan mengapa sistem enterprise dapat menjadi terlalu kompleks bahkan sebelum benar-benar digunakan.
Karena itu, requirement bukan sekadar dokumen untuk developer. Requirement adalah alat untuk menyamakan pemahaman antara bisnis dan teknologi.
Requirement yang Tidak Terlihat: Audit, Retensi, dan Regulasi
Ada satu kategori requirement yang hampir selalu dibahas terlambat.
Bukan karena tidak penting, tetapi karena sering dianggap urusan infrastructure.
Padahal dampaknya sampai ke domain model.
Contohnya:
- Berapa lama data pribadi boleh disimpan setelah relasi bisnis berakhir?
- Siapa yang berhak melihat data nasabah, dan bagaimana akses itu dibuktikan?
- Perubahan mana yang wajib memiliki audit trail lengkap beserta pelakunya?
- Apakah data tertentu wajib berada di dalam negeri?
- Apa yang harus terjadi ketika pemilik data meminta penghapusan?
Pertanyaan tersebut bukan detail teknis.
Itu adalah aturan bisnis yang berasal dari luar organisasi.
Di Indonesia, konteksnya nyata. Undang-Undang Pelindungan Data Pribadi menetapkan kewajiban terkait dasar pemrosesan, retensi, dan hak subjek data. Sektor keuangan memiliki lapisan tambahan melalui ketentuan OJK mengenai penyelenggaraan teknologi informasi, manajemen risiko, dan penggunaan pihak ketiga. Sektor kesehatan, publik, dan telekomunikasi punya ketentuannya sendiri.
Konsekuensinya langsung ke desain.
Jika data pribadi memiliki masa retensi tertentu, maka entity yang menyimpannya tidak bisa disebar bebas ke seluruh sistem. Semakin banyak salinan, semakin sulit dihapus.
Jika setiap perubahan limit kredit harus dapat diaudit, maka perubahan tersebut bukan sekadar update kolom. Itu adalah peristiwa bisnis yang harus tercatat.
Jika data tertentu hanya boleh diakses peran tertentu, maka batas akses itu ikut membentuk batas konteks.
Requirement semacam ini justru membantu menemukan boundary.
Data yang diatur ketat cenderung ingin dipisahkan, dibatasi aksesnya, dan dijaga lifecycle-nya. Itu sinyal domain, bukan sekadar sinyal keamanan.
Karena itu, pertanyaan compliance sebaiknya diajukan bersamaan dengan pertanyaan proses bisnis.
Bukan setelah architecture selesai digambar.
Bagaimana Jika Scope Sudah Dikunci?
Dalam praktiknya, tidak semua proyek dimulai dari ruang kosong.
Sering kali scope sudah tertulis di dokumen tender. Feature list sudah disetujui. Budget sudah ditetapkan. Timeline sudah dijanjikan ke manajemen.
Apakah prinsip ini menjadi tidak relevan?
Tidak. Yang berubah hanya caranya.
Discovery tidak harus berupa fase panjang berminggu-minggu. Yang dibutuhkan adalah mengubah cara membaca daftar fitur yang sudah ada.
Ambil satu contoh sederhana.
Dokumen tender menuliskan: “Sistem menyediakan modul approval dengan tiga level.”
Tanpa menambah scope, tim tetap dapat bertanya:
- Apa yang sebenarnya ingin dikendalikan dengan tiga level itu?
- Apakah levelnya mengikuti nilai transaksi, jabatan, atau jenis pengadaan?
- Apa yang terjadi hari ini ketika approver sedang tidak ada?
- Berapa lama proses ini berjalan sekarang, dan berapa target yang dianggap berhasil?
Pertanyaan tersebut tidak mengubah komitmen kontrak.
Tetapi jawabannya menentukan apakah yang dibangun adalah workflow engine yang fleksibel, atau tiga tahap approval statis yang akan direvisi tiga bulan kemudian.
Discovery di dalam scope yang terkunci berarti mempertahankan apa yang dijanjikan, sambil memastikan tim memahami mengapa hal itu diminta.
Dan ketika ditemukan bahwa fitur yang diminta tidak menyelesaikan masalah sebenarnya, temuan itu tetap harus disampaikan. Lebih murah dibahas di awal daripada ditemukan saat user acceptance test.
Dari Requirement ke Domain: Di Sinilah DDD Menjadi Relevan
Ketika business requirement sudah dipahami, tahap berikutnya adalah memahami domain.
Di sinilah Domain-Driven Design atau DDD menjadi relevan.
DDD sering disalahpahami sebagai kumpulan pattern pemrograman. Padahal nilai terbesar DDD justru berada pada bagaimana tim memahami kompleksitas bisnis sebelum memikirkan implementasi.
Ada dua perspektif penting:
Strategic Design digunakan untuk memahami domain, subdomain, bahasa bisnis, dan batas antar konteks.
Tactical Design digunakan untuk menerjemahkan pemahaman tersebut ke dalam detail model seperti entity, value object, aggregate, repository, dan domain service.a
Untuk aplikasi enterprise, strategic design perlu mendapat perhatian lebih dahulu.
Karena architecture yang baik bukan hanya persoalan bagaimana komponen software saling terhubung.
Architecture juga harus mencerminkan bagaimana bisnis bekerja.
Ubiquitous Language: Satu Bahasa, Satu Pemahaman
Salah satu konsep penting dalam DDD adalah ubiquitous language.
Intinya sederhana: bisnis dan tim teknologi perlu menggunakan bahasa yang sama di dalam konteks yang sama.
Bayangkan sebuah perusahaan menggunakan istilah “Customer”.
Di Sales, customer mungkin berarti perusahaan atau individu yang melakukan pembelian.
Di Billing, customer bisa berarti entitas yang menerima invoice.
Di Support, customer mungkin berarti pihak yang memiliki kontrak layanan aktif.
Secara bahasa, semuanya disebut customer.
Secara bisnis, belum tentu sama.
Jika perbedaan ini tidak disadari, masalah akhirnya masuk ke software architecture.
Nama API berbeda.
Struktur database berkembang berbeda.
Business rule saling bertabrakan.
Developer menerjemahkan requirement berdasarkan interpretasinya sendiri.
Pada akhirnya, masalah tersebut terlihat seperti masalah teknis.
Padahal sumbernya adalah domain yang belum dipahami dengan cukup jelas.
Ubiquitous language membantu memastikan istilah penting yang digunakan dalam meeting, requirement, diagram, API, domain model, sampai code memiliki makna yang konsisten dalam konteks tertentu.
Bounded Context: Jangan Paksa Semua Menjadi Satu Model
Setelah bahasa bisnis mulai jelas, pertanyaan berikutnya adalah:
Di mana batas sebuah model berlaku?
Inilah konsep bounded context.
Dalam sistem enterprise, tidak semua bagian bisnis harus menggunakan model yang sama.
Customer pada Sales tidak harus identik dengan Customer pada Billing.
Order pada Commerce tidak harus identik dengan Shipment pada Logistics.
Account pada Finance tidak harus identik dengan User pada Identity Management.
Memaksa semuanya menjadi satu model global sering terlihat sederhana pada awalnya.
Tetapi ketika sistem tumbuh, model tersebut menjadi semakin besar.
Satu perubahan dapat memengaruhi banyak modul.
Ownership menjadi kabur.
Tim menjadi saling bergantung.
Deployment menjadi lebih rumit.
Dan technical debt mulai terbentuk.
Bounded context memberikan batas yang lebih sehat: satu model digunakan dalam konteks yang memang membutuhkan model tersebut.
Dari sinilah architecture yang lebih modular dapat mulai dirancang.
Bounded Context Bukan Microservice
Perlu ditegaskan karena sering tertukar.
Bounded context adalah batas model dan bahasa. Microservice adalah batas deployment.
Keduanya bisa berhimpitan, tetapi tidak wajib.
Sebuah modular monolith dapat memiliki lima bounded context yang tegas di dalam satu aplikasi, dengan modul yang terpisah, kontrak antar modul yang jelas, dan ownership yang berbeda per tim.
Sebaliknya, sepuluh microservice yang berbagi satu model global bukan sepuluh bounded context. Itu satu model besar yang kebetulan di-deploy terpisah, dengan tambahan biaya jaringan dan operasional.
Bounded context tidak boleh dibuat hanya karena ingin memiliki banyak service.
Batas harus mengikuti batas bisnis yang bermakna.
Microservices bukan titik awalnya.
Domain adalah titik awalnya.
Conway’s Law: Boundary Juga Soal Tim
Ada satu faktor yang sering luput ketika bounded context dirancang.
Struktur tim.
Melvin Conway mengamati bahwa desain sistem cenderung meniru struktur komunikasi organisasi yang membangunnya.
Pengamatan tersebut masih berlaku sampai sekarang.
Jika satu bounded context dikerjakan oleh tiga tim yang berbeda dengan prioritas berbeda, batas itu akan sulit dipertahankan. Setiap tim akan menambahkan kebutuhannya sendiri ke dalam model yang sama.
Sebaliknya, jika satu tim harus mengurus lima context sekaligus, batas antar context cenderung memudar. Lebih cepat memanggil langsung daripada mendefinisikan kontrak.
Implikasinya cukup praktis.
Boundary yang tidak memiliki pemilik yang jelas biasanya tidak bertahan lama.
Karena itu, ketika menentukan bounded context, pertanyaannya tidak berhenti pada “di mana batas bisnisnya?”.
Perlu ditambahkan: siapa yang akan memiliki context ini? Siapa yang berhak memutuskan perubahan modelnya? Bagaimana context ini berkomunikasi dengan tim lain?
Dalam organisasi besar, hal ini bahkan bisa berjalan dua arah. Kadang struktur tim perlu disesuaikan agar architecture yang diinginkan benar-benar dapat dijalankan.
Architecture yang baik di atas kertas tetap akan runtuh jika tidak ada tim yang bertanggung jawab menjaganya.
Domain Event: Cara Sistem Saling Mengetahui
Ketika bounded context dipisahkan, muncul pertanyaan berikutnya:
Bagaimana satu konteks mengetahui sesuatu yang terjadi di konteks lain tanpa membuat keduanya terlalu bergantung?
Salah satu jawabannya adalah domain event.
Misalnya: Order Cancelled. Sebuah order telah dibatalkan.
Peristiwa tersebut dapat memiliki konsekuensi berbeda:
- Inventory mungkin perlu mengembalikan stok.
- Notification mungkin perlu mengirimkan informasi.
- Finance mungkin perlu melakukan adjustment.
- Customer service mungkin perlu memperbarui status kasus.
Yang menarik, masing-masing konteks tidak harus mengetahui seluruh proses internal konteks lainnya.
Yang dibagikan adalah fakta bisnis bahwa sesuatu telah terjadi.
Di sinilah domain event berbeda dari sekadar mekanisme teknis pengiriman message.
Event seperti “Payment Received” atau “Order Cancelled” memiliki makna bisnis.
Teknologi seperti message broker dapat digunakan untuk mengimplementasikannya, tetapi teknologi tersebut bukan inti konsepnya.
Business event adalah fakta. Teknologi adalah cara kita menyebarkan fakta tersebut.
Harga yang Harus Dibayar
Domain event mengurangi coupling, tetapi tidak gratis.
Konsistensi menjadi eventual. Ada jeda antara order dibatalkan dan stok kembali tersedia. Jeda tersebut harus dapat diterima secara bisnis, bukan sekadar diterima secara teknis.
Event bisa terkirim lebih dari sekali. Consumer harus idempotent.
Urutan event tidak selalu terjamin. Sistem perlu tahan terhadap event yang datang tidak berurutan.
Dan yang paling sering diremehkan: proses bisnis menjadi lebih sulit ditelusuri. Alur yang dulu terbaca dalam satu fungsi kini tersebar di beberapa konteks. Tanpa correlation id dan tracing yang memadai, debugging menjadi mahal.
Karena itu, domain event sebaiknya digunakan ketika memang ada beberapa konteks yang perlu bereaksi terhadap satu fakta bisnis.
Bukan karena arsitektur event-driven terdengar lebih modern.
Studi Kasus: Ketika Satu Kata Berarti Tiga Hal
Sebuah perusahaan distribusi dengan belasan cabang meminta pembangunan sistem order management terintegrasi.
Permintaannya terdengar jelas.
Satu sistem, satu data order, semua cabang terhubung, manajemen mendapat dashboard real time.
Feature list sudah tersusun. Rencana awal adalah membangun satu modul Order terpusat yang digunakan seluruh divisi.
Namun ketika proses bisnis ditelusuri, muncul temuan yang mengubah arah desain.
Kata “order” ternyata memiliki tiga arti berbeda.
Di Sales, order adalah komitmen pembelian dari pelanggan. Statusnya berubah ketika pelanggan menyetujui penawaran.
Di Warehouse, order adalah instruksi pengiriman. Satu order dari Sales bisa terpecah menjadi beberapa pengiriman, tergantung ketersediaan stok di gudang yang berbeda.
Di Finance, order baru dianggap ada ketika barang telah diterima dan menjadi dasar penagihan.
Ketiganya menggunakan istilah yang sama dalam rapat.
Ketiganya memiliki lifecycle yang berbeda.
Masalah bisnis yang sebenarnya juga menjadi lebih jelas. Keluhan utama manajemen bukan pada proses input order, melainkan pada selisih antara barang yang dikirim dan yang tertagih. Rekonsiliasi dilakukan manual dan memakan waktu di akhir bulan.
Jika satu model Order global tetap dipaksakan, sistem hanya akan memindahkan masalah tersebut ke dalam satu tabel besar dengan puluhan status.
Pendekatan yang diambil kemudian berbeda.
Tiga bounded context dipisahkan: Sales Order, Fulfillment, dan Billing. Masing-masing memiliki model dan istilah sendiri yang disepakati bersama divisi terkait.
Komunikasi antar context menggunakan domain event yang bermakna bisnis, seperti order dikonfirmasi, pengiriman diterima, dan penagihan diterbitkan.
Rekonsiliasi tidak lagi menjadi proses manual di akhir bulan, melainkan konsekuensi dari peristiwa yang tercatat sepanjang proses berjalan.
Yang menarik, hasil akhirnya tetap berupa satu aplikasi. Bukan microservices.
Modular monolith dinilai cukup karena volume transaksi dan jumlah tim belum menuntut pemisahan deployment.
Yang berubah bukan teknologinya.
Yang berubah adalah cara masalah bisnis dipahami sebelum teknologinya dipilih.
Baru Setelah Itu: System Architecture
Setelah bisnis, domain, bahasa, dan boundary mulai jelas, barulah architecture mendapatkan konteks yang benar.
Urutannya dapat dilihat sederhana:
Business Requirement
↓
Domain & Bounded Context
↓
System Architecture
↓
Application
↓
API & Integration
↓
Database
↓
Infrastructure
↓
MonitoringArchitecture bukan sekadar diagram kotak dan panah.
Architecture adalah keputusan mengenai bagaimana sistem memenuhi kebutuhan bisnis dalam kondisi nyata.
- Apa yang harus highly available?
- Apa yang membutuhkan low latency?
- Komponen mana yang dapat berubah secara independen?
- Data mana yang menjadi source of truth?
- Sistem mana yang harus terisolasi?
- Bagaimana failure ditangani?
- Bagaimana sistem dapat berkembang ketika organisasi bertambah besar?
Pertanyaan semacam ini jauh lebih penting dibanding sekadar memilih teknologi yang sedang populer.
API dan Integration: Sistem Enterprise Tidak Pernah Berdiri Sendiri
Salah satu karakteristik aplikasi enterprise adalah banyaknya ketergantungan.
Aplikasi baru mungkin harus berkomunikasi dengan ERP, HRIS, CRM, payment gateway, warehouse system, legacy application, data warehouse, atau sistem pihak ketiga.
Karena itu, API dan integration design tidak boleh diperlakukan sebagai pekerjaan setelah aplikasi selesai.
Integration harus mengikuti business boundary dan ownership.
Jangan hanya bertanya:
“Bagaimana kita membuat API Customer?”
Tanyakan:
Customer versi siapa? Untuk proses apa? Siapa pemilik datanya?
Pertanyaan tersebut membantu mencegah API menjadi sekadar representasi tabel database.
Dalam integrasi dengan sistem legacy, pendekatan seperti Anti-Corruption Layer juga dapat digunakan agar model internal aplikasi baru tidak harus mengikuti struktur dan istilah sistem lama.
Lapisan ini bertugas menerjemahkan. Ketika ERP lama mengirim struktur data dengan istilah dan asumsinya sendiri, terjemahan terjadi di batas, bukan di dalam domain model.
Tujuannya bukan membuat integration terlihat canggih.
Tujuannya menjaga domain baru tetap bersih.
Database Bukan Pusat Semesta Aplikasi
Hal yang sama berlaku untuk database.
Dalam banyak proyek, architecture secara tidak sadar dibuat berdasarkan schema database yang sudah ada.
Padahal database seharusnya mendukung domain, bukan menentukan seluruh domain.
Hal yang lebih penting untuk dipahami adalah:
- Siapa pemilik data?
- Di mana consistency boundary berada?
- Data mana yang transactional?
- Bagaimana lifecycle data berjalan?
- Apa yang harus menjadi source of truth?
Ada satu pola yang perlu diwaspadai secara khusus: shared database sebagai sarana integrasi.
Polanya terlihat praktis. Beberapa aplikasi membaca dan menulis ke database yang sama. Tidak perlu API, tidak perlu kontrak.
Masalahnya muncul belakangan.
Skema database berubah menjadi kontrak publik yang tidak pernah disepakati secara resmi. Satu perubahan kolom dapat merusak aplikasi lain yang tidak diketahui pemiliknya. Business rule tersebar di beberapa aplikasi yang menulis ke tabel yang sama. Dan tidak ada yang benar-benar memiliki data tersebut.
Integrasi melalui database memang lebih cepat di awal.
Tetapi ia menghapus batas yang justru sedang kita bangun.
Ketika pertanyaan kepemilikan dan boundary sudah jelas, keputusan database menjadi lebih rasional.
PostgreSQL, MySQL, SQL Server, NoSQL, atau teknologi lainnya hanyalah alat.
Tidak ada database yang dapat menyelamatkan domain model yang memang salah.
Infrastructure dan Monitoring Bukan Tahap Terakhir
Setelah application, API, dan database dirancang, infrastructure menentukan di mana sistem akan berjalan.
Cloud atau on-premise?
Container atau virtual machine?
Bagaimana scalability, backup, disaster recovery, dan security?
Tetapi pekerjaan belum selesai ketika sistem sudah production.
Justru di sana siklus berikutnya dimulai.
Monitoring harus memberi tahu apakah sistem benar-benar memenuhi requirement.
Misalnya business requirement menetapkan aplikasi harus tersedia 24/7.
Maka technical implementation harus diterjemahkan menjadi availability target, monitoring, logging, alerting, backup, recovery strategy, dan capacity planning.
Dengan demikian, monitoring bukan garis finish.
Ia menjadi loop:
Requirement → Domain → Architecture → Technology → Operation → Monitoring → RequirementSistem enterprise yang sehat bukan sistem yang selesai sekali.
Ia adalah sistem yang terus dievaluasi terhadap kebutuhan bisnis yang juga terus berubah.
Jadi, Apa Urutan yang Benar?
Membangun aplikasi enterprise bukan berarti harus menghindari coding.
Coding tetap penting.
Technology tetap penting.
Architecture tetap penting.
Tetapi semuanya harus hadir pada waktunya.
Urutan berpikir yang lebih sehat adalah:
1. Understand the Business
Pahami masalah, stakeholder, proses, dan outcome.
2. Define the Domain
Sepakati bahasa dan pahami batas bisnis.
3. Design the Architecture
Tentukan bagaimana domain direpresentasikan dalam sistem.
4. Design Integration
Tentukan bagaimana konteks dan sistem eksternal berkomunikasi.
5. Build the Application
Baru masuk ke implementation.
6. Design Data & Infrastructure
Pastikan sistem mampu beroperasi dan berkembang.
7. Monitor & Improve
Ukur kembali apakah technology benar-benar memberikan business value.
Ini Bukan Waterfall
Urutan di atas mudah disalahpahami sebagai tujuh fase berurutan yang harus selesai satu per satu.
Bukan itu maksudnya.
Ini adalah urutan prioritas berpikir, bukan gerbang fase.
Dalam praktiknya, sebagian domain justru baru dipahami setelah ada yang dibangun. Prototype, spike, dan walking skeleton adalah cara yang sah untuk menemukan requirement. Kadang satu layar sederhana yang dicoba pengguna mengungkap lebih banyak daripada tiga kali workshop.
Yang membedakan bukan panjangnya dokumen di awal.
Yang membedakan adalah pada skala apa pun, urutannya tetap sama.
Sebelum membangun satu fitur pun, tim seharusnya sudah bisa menjawab: masalah apa yang diselesaikan fitur ini, domain mana yang tersentuh, dan bagaimana keberhasilannya diukur.
Tiga pertanyaan itu bisa dijawab dalam lima menit untuk satu fitur kecil, atau dalam dua minggu untuk sebuah sistem baru.
Yang tidak boleh terjadi adalah melewatinya sama sekali.
Prinsip utamanya tetap satu: gunakan complexity hanya ketika business complexity memang membutuhkannya.
Tidak setiap proyek harus menggunakan DDD penuh, microservices, atau event-driven architecture.
Kesimpulan: Jangan Bangun Sistem yang Hebat untuk Masalah yang Salah
Aplikasi enterprise yang baik bukan aplikasi dengan technology paling banyak.
Bukan pula aplikasi dengan architecture diagram paling rumit.
Aplikasi yang baik adalah aplikasi yang struktur teknologinya benar-benar mengikuti struktur masalah bisnis yang ingin diselesaikan.
Karena itu, sebelum developer menulis baris kode pertama, organisasi seharusnya sudah memiliki jawaban terhadap pertanyaan yang lebih fundamental:
- Masalah apa yang kita selesaikan?
- Domain apa yang terlibat?
- Di mana batasnya?
- Bahasa apa yang disepakati?
- Bagaimana konteks bisnis saling berkomunikasi?
Barulah technology mengambil peran.
Pendekatan semacam inilah yang membedakan software engineering yang sekadar membangun aplikasi dengan engineering yang membangun business capability.
Bagi Sagara, technology bukan tujuan akhir. Ia adalah instrumen untuk menerjemahkan kebutuhan bisnis menjadi sistem yang dapat digunakan, diintegrasikan, dioperasikan, dan dikembangkan.
Itulah semangat di balik Sagara Xinix IT Solution POWERHOUSE: bukan sekadar membangun software, tetapi membangun solusi technology yang berangkat dari pemahaman terhadap bisnis.
Karena pada akhirnya, pertanyaan yang paling penting bukan:
“Seberapa canggih aplikasi yang kita bangun?”
Melainkan:
“Seberapa tepat aplikasi tersebut menyelesaikan masalah yang memang penting bagi bisnis?”
Diskusikan Arsitektur Sistem Anda
Sedang merencanakan sistem enterprise baru, atau sedang mempertimbangkan modernisasi sistem yang berjalan?
Tim Sagara dapat membantu memetakan domain, menentukan boundary, dan merancang architecture yang sesuai dengan kebutuhan bisnis Anda.
Hubungi kami untuk sesi diskusi arsitektur → hello@sagara.id
FAQ
Apakah Domain-Driven Design hanya untuk aplikasi enterprise?
Tidak. DDD paling bernilai ketika domain memiliki kompleksitas bisnis yang tinggi. Untuk aplikasi sederhana dengan business rule minimal, penerapan DDD secara penuh dapat menjadi overhead yang tidak diperlukan.
Apa perbedaan DDD dan microservices?
DDD adalah pendekatan untuk memahami dan memodelkan domain bisnis. Microservices adalah architectural style. DDD dapat membantu menentukan boundary service, tetapi menggunakan DDD tidak otomatis berarti aplikasi harus dibangun sebagai microservices.
Apa itu bounded context?
Bounded context adalah batas tempat sebuah domain model dan bahasa bisnis memiliki arti yang konsisten. Konsep ini membantu menghindari satu model global yang terlalu kompleks.
Apa itu ubiquitous language?
Ubiquitous language adalah bahasa bersama antara domain expert dan tim teknologi dalam konteks tertentu. Tujuannya mengurangi perbedaan interpretasi terhadap istilah dan business rule.
Apakah aplikasi enterprise harus menggunakan microservices?
Tidak. Pilihan architecture harus mengikuti kebutuhan bisnis, complexity, coupling, scalability, ownership, security, dan operational requirements. Dalam kondisi tertentu, modular monolith justru dapat menjadi pilihan yang lebih tepat.
Bagaimana jika scope proyek sudah ditetapkan dalam kontrak?
Prinsipnya tetap berlaku, hanya caranya yang berbeda. Tim tidak perlu mengubah daftar fitur yang sudah disepakati, tetapi tetap dapat menggali alasan bisnis di balik setiap fitur. Pemahaman tersebut menentukan kualitas desain, meskipun scope-nya sudah terkunci.
Apakah pendekatan ini sama dengan waterfall?
Tidak. Urutan yang dijelaskan adalah prioritas berpikir, bukan fase yang harus selesai berurutan. Prototype dan eksperimen tetap dapat digunakan untuk menemukan requirement. Yang penting, setiap pekerjaan tetap dimulai dari pemahaman terhadap masalah bisnisnya.