# BAB 1: DDD UNTUK SAYA (DDD FOR ME) **Buku:** Domain-Driven Design Distilled **Penulis:** Vaughn Vernon **Penerjemah:** Everest ERP Architecture Team --- Anda ingin meningkatkan keahlian Anda dan memperbesar keberhasilan proyek-proyek Anda. Anda bersemangat membantu bisnis Anda bersaing di tingkat tertinggi menggunakan perangkat lunak yang Anda ciptakan. Anda ingin mengimplementasikan perangkat lunak yang tidak hanya memodelkan kebutuhan bisnis Anda secara benar, tetapi juga mampu berkinerja pada skala besar menggunakan arsitektur perangkat lunak paling mutakhir. Mempelajari *Domain-Driven Design* (DDD), dan mempelajarinya dengan cepat, dapat membantu Anda mencapai semua itu dan lebih banyak lagi. DDD adalah sekumpulan alat yang membantu Anda merancang dan mengimplementasikan perangkat lunak yang memberikan nilai bisnis tinggi, baik secara strategis maupun taktis. Organisasi Anda tidak bisa menjadi yang terbaik dalam segala hal, sehingga organisasi harus memilih secara cermat di area mana ia harus unggul. Alat-alat pengembangan strategis DDD membantu Anda dan tim Anda membuat pilihan desain perangkat lunak dan keputusan integrasi terbaik yang kompetitif bagi bisnis Anda. Organisasi Anda akan mendapatkan manfaat paling besar dari model perangkat lunak yang secara eksplisit mencerminkan kompetensi intinya (*core competencies*). Alat pengembangan taktis DDD dapat membantu Anda dan tim Anda merancang perangkat lunak yang berguna yang secara akurat memodelkan operasi bisnis yang unik. Organisasi Anda akan mendapatkan keuntungan dari berbagai opsi untuk menyebarkan (*deploy*) solusinya di berbagai infrastruktur, baik di server lokal (*on-premise*) maupun di *cloud*. Dengan DDD, Anda dan tim Anda dapat menjadi pihak yang menghadirkan desain dan implementasi perangkat lunak paling efektif yang diperlukan untuk sukses dalam lanskap bisnis yang kompetitif saat ini. Dalam buku ini, saya telah menyarikan DDD untuk Anda, dengan perlakuan ringkas dan padat baik pada alat pemodelan strategis maupun taktis. Saya memahami tuntutan unik pengembangan perangkat lunak dan tantangan yang Anda hadapi saat Anda berupaya meningkatkan keahlian Anda di industri yang bergerak cepat. Anda tidak selalu memiliki waktu berbulan-bulan untuk membaca topik mendalam seperti DDD, namun Anda tetap ingin segera menerapkan DDD dalam pekerjaan nyata secepat mungkin. Saya adalah penulis buku terlaris *Implementing Domain-Driven Design* (IDDD), dan saya juga menciptakan serta mengajar di *IDDD Workshop* 3 hari. Sekarang saya menulis buku ini untuk menghadirkan DDD kepada Anda dalam bentuk yang sangat padat dan ringkas (*aggressively condensed form*). Ini semua adalah bagian dari komitmen saya untuk membawa DDD ke setiap tim pengembangan perangkat lunak, tempat di mana DDD seharusnya berada. --- ### Apakah DDD Menyakitkan / Sulit? (*Will DDD Hurt?*) Anda mungkin pernah mendengar bahwa DDD adalah pendekatan pengembangan perangkat lunak yang rumit. Rumit? Tentu saja tidak harus rumit secara kebutuhan. Memang, DDD adalah kumpulan teknik tingkat lanjut yang digunakan pada proyek perangkat lunak yang kompleks. Karena kekuatannya dan banyaknya hal yang harus Anda pelajari, tanpa bimbingan ahli, mempraktikkan DDD secara mandiri memang terasa menakutkan. Anda mungkin juga menemukan bahwa beberapa buku DDD lainnya memiliki tebal ratusan halaman dan jauh dari kata mudah untuk dikonsumsi dan diterapkan. Diperlukan banyak kata bagi saya untuk menjelaskan DDD secara sangat rinci dalam buku *Implementing Domain-Driven Design* (IDDD) sebagai referensi implementasi lengkap pada lebih dari selusin topik dan alat DDD. Buku ringkas baru ini disediakan untuk membiasakan Anda dengan bagian-bagian terpenting dari DDD secepat dan sesederhana mungkin. Mengapa? Karena beberapa orang merasa kewalahan dengan buku teks tebal dan membutuhkan panduan ringkas untuk membantu mereka mengambil langkah awal adopsi. Saya mendapati bahwa mereka yang menggunakan DDD membaca ulang literatur tersebut beberapa kali. Anda bahkan mungkin menyimpulkan bahwa Anda tidak akan pernah merasa cukup belajar, sehingga Anda akan menggunakan buku ini sebagai referensi cepat, dan merujuk ke buku lain untuk detail lebih lanjut, berkali-kali seiring keahlian Anda terasah. Bagi mereka yang kesulitan "menjual" DDD kepada rekan kerja dan tim manajemen yang sangat penting, buku ini akan membantu Anda melakukannya—bukan hanya dengan menjelaskan DDD dalam format ringkas, tetapi juga dengan menunjukkan bahwa ada alat-alat praktis yang tersedia untuk mempercepat dan mengelola penggunaannya. Kabar baiknya adalah: **DDD tidak harus menyakitkan.** Karena Anda mungkin sudah menghadapi kompleksitas dalam proyek Anda sehari-hari, Anda dapat belajar menggunakan DDD untuk mengurangi rasa sakit dalam menaklukkan kompleksitas tersebut. --- ### Desain yang Baik, Buruk, dan Efektif (*Good, Bad, and Effective Design*) Sering kali orang berbicara tentang desain yang baik dan desain yang buruk. Desain seperti apa yang Anda lakukan? Banyak tim pengembangan perangkat lunak bahkan tidak memikirkan desain sedikit pun. Sebaliknya, mereka melakukan apa yang saya sebut **"the task-board shuffle"** (menggeser-geser papan tugas). Di sinilah tim memiliki daftar tugas pengembangan, seperti pada backlog produk Scrum, dan mereka hanya memindahkan catatan tempel (*sticky note*) dari kolom "To Do" ke kolom "In Progress". Mengambil item backlog dan melakukan "pergeseran papan tugas" dianggap sebagai keseluruhan wawasan yang mendalam, dan sisanya diserahkan pada aksi heroik menulis kode (*coding heroics*) saat programmer memberondong kode sumber. Hal ini jarang sekali menghasilkan hasil terbaik, dan harga yang harus dibayar oleh bisnis biasanya merupakan harga tertinggi untuk desain yang sama sekali tidak ada tersebut. Hal ini sering terjadi karena tekanan untuk merilis perangkat lunak sesuai jadwal yang tanpa henti, di mana manajemen menggunakan Scrum terutama untuk mengontrol garis waktu (*timeline*) daripada memberi ruang bagi salah satu prinsip terpenting Scrum: **akuisisi pengetahuan (*knowledge acquisition*)**. Ketika saya berkonsultasi atau mengajar di berbagai perusahaan, saya umumnya menemukan situasi yang sama. Proyek-proyek perangkat lunak berada dalam bahaya, dan seluruh tim dipekerjakan hanya untuk menjaga sistem tetap menyala dan berjalan, menambal kode dan data yang rusak setiap hari (*patching code and data daily*). Berikut adalah beberapa masalah berbahaya yang saya temukan, yang menariknya dapat dicegah dengan mudah oleh DDD: 1. **Pengembangan Perangkat Lunak Dianggap Sebagai Pusat Biaya (*Cost Center*):** Pengembangan software dianggap beban biaya alih-alih pusat keuntungan (*profit center*). Bisnis memandang komputer dan perangkat lunak sebagai gangguan operasional yang terpaksa ada, bukan sebagai sumber keunggulan strategis. 2. **Pengembang Terlalu Terpaku pada Teknologi (*Shiny Objects*):** Developer terlalu sibuk dengan teknologi dan mencoba menyelesaikan masalah menggunakan teknologi daripada pemikiran dan desain yang matang. Hal ini menyebabkan pengembang terus-menerus mengejar tren teknologi terbaru (*shiny objects*). 3. **Basis Data Diberikan Prioritas Terlalu Tinggi (*Database-Centric*):** Sebagian besar diskusi tentang solusi berpusat di sekitar database dan model data tabular, bukan di sekitar proses bisnis dan alur operasi bisnis yang nyata. 4. **Pengembang Tidak Menamai Objek Sesuai Tujuan Bisnis:** Pengembang tidak memberi penekanan yang tepat pada penamaan objek dan operasi sesuai dengan tujuan bisnis yang diembannya. Ini menyebabkan jurang pemisah (*large chasm*) yang besar antara model mental yang dimiliki bisnis dan perangkat lunak yang diserahkan pengembang. 5. **Kurangnya Kolaborasi dengan Pihak Bisnis:** Pemangku kepentingan bisnis menghabiskan terlalu banyak waktu bekerja secara terisolasi menghasilkan dokumen spesifikasi tebal yang tidak pernah dibaca siapa pun atau hanya dibaca sebagian oleh pengembang. 6. **Melahirkan Bola Lumpur Raksasa (*Big Ball of Mud*):** Pengembang menghasilkan sistem monolitik kusut tanpa batas eksplisit, di mana konsep-konsep yang tidak berhubungan bercampur aduk di banyak modul dan saling bertentangan. 7. **Menaruh Logika Bisnis di Tempat yang Salah:** Pengembang menempatkan logika bisnis di komponen User Interface (View), Controller, dan komponen persistensi/database. Developer juga sering melakukan operasi penyimpanan database langsung di tengah-tengah logika bisnis. 8. **Kueri Database yang Lambat, Rusak, dan Saling Kunci (*Locking Database Queries*):** Kueri database yang buruk memblokir pengguna lain dalam menjalankan operasi bisnis yang sensitif terhadap waktu. 9. **Abstraksi yang Salah (*Wrong Abstractions*):** Pengembang mencoba memenuhi semua kebutuhan masa depan yang dibayangkan dengan membuat solusi yang terlalu umum (*overly generalizing*) daripada menyelesaikan kebutuhan bisnis nyata yang konkret. 10. **Layanan yang Terikat Sangat Erat (*Strongly Coupled Services*):** Sebuah operasi di satu service memanggil service lain secara langsung untuk operasi penyeimbang, memicu kegagalan berantai dan ketidaksesuaian data (*unreconciled data*). Semua ini tampaknya terjadi atas dasar ilusi bahwa *"tanpa desain menghasilkan perangkat lunak yang lebih murah"*. Padahal, ilusi "No Design" adalah kesalahan fatal. Perhatikan kutipan bijak ini: > *"Pertanyaan mengenai apakah desain itu perlu atau terjangkau sebenarnya sama sekali tidak relevan: desain itu tak terelakkan. Alternatif dari desain yang baik adalah desain yang buruk, bukan tanpa desain sama sekali."* > — **Douglas Martin**, *Book Design: A Practical Introduction* Jika ada lima pengembang yang bekerja tanpa desain, "No Design" sebenarnya akan menghasilkan campuran lima desain berbeda yang dipaksakan menjadi satu. Anda mendapatkan campuran lima interpretasi bahasa bisnis karangan sendiri yang dibuat tanpa bimbingan Pakar Domain (*Domain Experts*). Intinya: **Kita memodelkan sesuatu baik kita menyadarinya atau tidak.** Ini bisa diibaratkan dengan pembangunan jalan. Beberapa jalan kuno berawal dari jalur gerobak yang lambat laun menjadi jalan setapak tanah yang berliku tanpa arah jelas. Suatu saat jalan itu diaspal hanya karena jalan itu sudah ada, bukan karena dirancang dengan baik. Akibatnya jalan tersebut sempit, macet, dan berbahaya. Sebaliknya, jalan raya modern direncanakan dan dirancang berdasarkan studi cermat mengenai populasi, lingkungan, dan arus lalu lintas yang terukur. Perangkat lunak dapat dimodelkan dari kedua sudut pandang tersebut. --- ### Desain Efektif (*Effective Design*) Kata yang sangat erat kaitannya dengan *baik* adalah **efektif** (*effective*). Desain yang efektif memenuhi kebutuhan organisasi bisnis hingga mampu membedakan dirinya dari para pesaing melalui perangkat lunak. Desain yang efektif memaksa organisasi untuk memahami di area mana ia harus unggul (*excel*) dan digunakan untuk memandu penciptaan model perangkat lunak yang benar. Dalam Scrum, akuisisi pengetahuan dilakukan melalui eksperimen dan pembelajaran kolaboratif yang disebut sebagai "membeli informasi" (*buying information*). Pengetahuan tidak pernah gratis, namun DDD menyediakan cara bagi Anda untuk mempercepat perolehannya. Sebagaimana dikatakan oleh Steve Jobs: > *"Kebanyakan orang membuat kesalahan dengan berpikir bahwa desain adalah bagaimana tampilannya. Orang berpikir desain adalah kulit luar pembungkus—bahwa desainer diserahi kotak ini dan diberi tahu: 'Buatlah terlihat bagus!' Bukan itu yang kami anggap sebagai desain. Desain bukan hanya bagaimana tampilannya dan bagaimana rasanya. **Desain adalah bagaimana cara kerjanya (Design is how it works).**"* Dalam perangkat lunak, desain yang efektif adalah yang paling penting. --- ### Garis Besar Desain Strategis & Taktis 1. **Desain Strategis (*Strategic Design*):** - Dimulai sebelum masuk ke detail implementasi kode. - Menggunakan sapuan kuas lebar untuk menyoroti apa yang penting secara strategis bagi bisnis Anda, bagaimana membagi pekerjaan berdasarkan tingkat kepentingannya, dan bagaimana mengintegrasikannya dengan baik. - Memisahkan model domain menggunakan pola **Bounded Contexts**. - Mengembangkan **Ubiquitous Language** yang disepakati bersama antara pengembang dan Pakar Domain di dalam batas konteks tersebut. - Menggunakan **Subdomains** untuk membedakan antara *Core Domain* (keunggulan kompetitif), *Supporting Subdomain*, dan *Generic Subdomain*. - Menggunakan **Context Mapping** untuk memetakan hubungan antar-tim dan integrasi teknis. 2. **Desain Taktis (*Tactical Design*):** - Seperti menggunakan kuas tipis untuk melukis detail halus dari model domain Anda. - Menggunakan pola **Aggregates** (Agregat) untuk mengelompokkan Entitas dan Value Object ke dalam batasan konsistensi transaksional yang pas. - Menggunakan **Domain Events** untuk mencatat kejadian penting di masa lalu secara eksplisit dan mempublikasikannya ke sistem lain (mendukung *Event Sourcing* dan *Event-Driven Architecture*). 3. **Proses Belajar dan Penyempurnaan Pengetahuan (*Knowledge Crunching*):** - DDD mengajarkan cara berpikir untuk membantu Anda dan tim menyaring dan memurnikan pengetahuan melalui eksplorasi, pertanyaan kritis, dan alat cepat seperti **Event Storming**.