Akhirnya DDD Juga

Judul panjang buku ini adalah, "Domain-Driven Design: Tackling Complexity in the Heart of Software". Kalo koding kita nggak kompleks, ya taruh buku ini di rak. Ngapain pake bawa-bawa DDD segala. Itu namanya sok pinter. Ya, kecuali kalo kita butuh pembenaran buat bikin bingung bos-bos C-level biar dianggap ahli. Ya, sebenarnya ini salah mereka karena ngrekrut kita tapi nggak bisa tahu kemampuan kita sebenarnya. Tapi, mungkin gaji udah terlanjur kegedean. Ya gimana, daripada dipecat karena kerjaan kita nggak kelar-kelar, mending menggertak para bos pake istilah yang rumit-rumit. Padahal ngoding CRUD doang, bilangnya DDD super scalable high availability dan tetek bengek sebagainya. Padahal, butuh 1000 RPS aja belum tentu sebulan sekali. Sah sih, tapi tidak bermoral.

Bukan DDD namanya kalo kita nggak ngerti domain yang kita garap. Bukan DDD kalo kode kita nggak nyambung sama apa yang diomongin sama para domain expert. Konsep ini adalah konsep pertama yang saya fahami, bahkan lama sebelum saya menamatkan buku ini. Dan, ini adalah konsep dasar yang paling penting sebelum beranjak ke konsep-konsep taktis macam repository, entity, ataupun value object.

Ada istilah Eric Evans untuk hal ini, "letting the bones show". Bahkan sampai ke tataran UI pun, kita harus bicara dengan bahasa yang benar. Sistem yang kita bikin, harus bisa menampakkan modelnya kepada pengguna, dan model itu berkelakuan sama seperti yang diharapkan penggunanya.

Buku ini beberapa kali menyebut "Design Patterns". Bahkan ada satu bab khusus yang membahas hubungan DDD dengan Design Patterns. Jadi, kalo kita belum baca Design Patterns terus baca buku ini, kita akan beberapa kali kehilangan konteks. Kayaknya sih nggak perlu faham Design Patterns sampai nglotok untuk bisa faham buku ini. Ya, paling tidak pernah tahu sekilas lah supaya nggak roaming roaming amat.

Salah satu pencerahan terpenting yang saya dapat dari buku ini adalah "Refactoring towards Deeper Insight". Kan ya, judul buku ini "Domain Driven Design". Anggapan saya, ini yang bikin adalah arsitek perangkat lunak versi menara gading. Bikin rancangan sekali, biar mantep pake metode DDD. Dijamin, tahan banting dan bisa menghadapi badai perubahan kebutuhan.

Ternyata bukan begitu! Suatu terobosan yang membuat sistem jadi lebih sederhana itu terjadi karena seringnya perubahan model kecil-kecil yang dilakukan. Kadangkala, muncullah suatu terobosan yang membuat implementasi perkodingan jadi lebih sederhana dan bagian-bagian yang tadinya mengganggu bisa dibuang. Ndak ada itu namanya orang melamunkan arsitektur sambil ngerokok dan ngopi selama seminggu penuh sampai tidak mandi. Ya bayangan saya, melamun dua hari saja, begitu dapat sesuatu yang bisa dicoba, dikoding dulu. Nggak cocok, nanti bisa dirubah sambil jalan. Yang penting kan kontraknya tidak berubah.

Bahkan, kontrak terhadap bagian-bagian lain berubah pun bisa saja. Kalo kerumitan yang ada sekarang itu membuat perusahaan ilang duit, ya kadang-kadang perlu dilakukan perubahan mendasar memang. Perubahan kayak gini bukannya untuk ditakuti, tapi untuk diatur sedemikian rupa. Misal, perubahan arsitektur bisa bikin biaya AWS turun. Tapi, "breaking change" ini juga ada harganya. Risikonya bisa bikin sesuatu yang tadinya jalan jadi nggak jalan.

Sudah jelas, rancangan itu tumbuh. Sudah jelas, pertumbuhan itu membutuhkan banyak refactoring. Mana ada refactoring tanpa ada automated unit tests. Jadi, kalo ada orang berkoar-koar DDD tapi nggak memperhatikan soal testing, orang itu palsu. Refactor tanpa automated unit tests adalah kengawuran tingkat Dewa. Mau ngubah sering-sering gimana, wong setiap kali diubah pasti ada kemungkinan jadi nggak jalan.

XP disebut buku ini ketika membahas Continuous Integration, di bagian paling akhir di buku ini. XP itu adalah potret agile yang sebenarnya. Kalo mau agile dan bener ya ikutilah XP, bukan SCRUM. SCRUM itu pengkhianat agile kalo menurut saya. Tapi, konteks XP yang disebut di buku ini adalah soal continuous integration. Automated unit tests dan continuous integration, dari dua hal ini kalian tahu kan DDD itu sebenarnya arahnya ke mana?

Eric Evans itu nggak ahli functional programming kalo nggak dibilang nggak ngerti. Di bukunya dia nggak nyebut-nyebut FP sama sekali kok. Kalo mau belajar DDD dari sumbernya memang mau tidak mau harus belajar OOP. Kalau ada yang bilang DDD itu bisa dilakukan dengan functional programming, itu pasti aliran sesat yang ngaku-ngaku. Judulnya sama, "Domain Driven Design", tapi pasti isinya lain.

Jangan khawatir, sesat juga nggak papa kok. Saya juga baca dikit-dikit "Domain Modelling Made Functional". Malah, bukunya jauh lebih asyik dari buku ini. Pengarangnya itu yang pinter. Dia bisa mengadaptasi beberapa ide DDD untuk diterapkan ke dalam bahasa F#. Dia juga bisa menjelaskan Monad dan computation expression pake bahasa yang sederhana. Keren abis itu!

Yang jelas, OOP itu adalah paradigma yang selalu saya pakai sejak lama. OOP itu susah, dan saya mulai enek sama OOP. Di buku ini, OOP-nya kental sekali, terutama untuk melakukan "domain modelling". Kalo berurusan sama masalah yang rumit dan pelik, sementara senjata kita cuma ada prosedural dan OOP, jelas mau tidak mau saya akan memilih OOP. Saya belum ahli FP, tapi, yang namanya masalah rumit akan bakalan tetap rumit, mau diselesaikan pake paradigma apapun. Mungkin saya nggak akan lagi pusing soal interaksi antarobjek, tapi soal komposisi fungsi, monad, typeclass, generic, computation expression dan lain sebagainya. Bisa jadi, masalah satu enak diselesaikan dengan OOP, masalah lain lagi enak diselesaikan dengan FP. Duh, saya jadi pengen baca bukunya Scott Wlaschin lagi.

Berhubung saya ini pinter tapi nggak jenius, setelah baca sekali buku ini saya merasa nggak faham. Untuk buku-buku dengan tingkatan sulit, semisal "Design Patterns", saya harus baca sampai lima kali baru merasa ngerti. Buku dengan tingkatan menengah, macam "Clean Architecture", saya harus baca tiga kali baru merasa ngerti. Buku "Code Complete" dan "Clean Code", satu hingga dua kali sudah cukup. Baca lagi kalo mau nginget isinya soal apa.

Setelah baca buku ini, saya merasa masih nggak dapet konsepnya. Saya akhirnya tahu kalo buku ini OOP banget, tapi saya belum dapet "ooo"-nya yang bikin banyak orang keranjingan sama buku ini. Ini beda ketika saya dapet "ooo" dari buku "Clean Architecture" atau dari "Test Driven Development". Kalo belum sampai "ooo", berarti saya belum tahu apa sebenarnya yang ingin disampaikan sama Eric Evans.

Ternyata, ketika orang belajar DDD, mereka tidak cuma baca buku ini. Mereka juga baca buku yang lain. Mungkin, saya harus baca buku-buku yang lain baru saya ngeh. Sementara ini, ada empat buku lain yang saya pengen baca:

Kalo mau dari "domain crunching", mungkin saya harus pindah empat perusahaan dulu. Padahal, jarang-jarang ada startup yang punya kode baru yang dari awal banget. Untungnya, untuk praktik yang pertama kali, saya ada bahan di kantor saya. Kita sedang menggarap sistem "Self-Sovereign Identity" dari awal. Lumayan lah. Ato, bisa juga berkaca dari perusahaan-perusahaan terdahulu. Saya sudah kenal paling tidak hingga lima domain, "motor controller", "game backend", "learning platform", sama "military decision making process".

Sayangnya, di masa lalu saya nggak ngerti "refactoring towards deeper insights", juga nggak ngerti "anti corruption layer". Satu-satunya yang bisa saya praktikkan ya apa yang saya bikin sekarang. SSI cocok jadi target DDD karena sumbernya banyak dan masalahnya memang rumit. Lumayan sedap ini.