Selasa, 16 Juni 2015

Apakah Domain Driven Design ( DDD ) itu?

Software development seringkali diaplikasikan untuk mengotomatisasi proses yang terjadi di dunia nyata atau menyediakan solusi terhadap business problem. Bisnis proses yang hendak diotomatisasi merupakan domain dari software tersebut. Jadi kita harus sadar kalau software tersebut berasal dari dan relasinya sangat erat dengan domain tersebut.
Software terdiri dari code. Kita mungkin menghabiskan begitu banyak waktu dengan code dan melihat software tersebut hanya merupakan kumpulan dari object dan method.


Mari kita lihat apa yang terjadi pada proses pembuatan mobil. Pekerja yang dilibatkan pada proses manufacturing yg otomatis tersebut mungkin sangat ahli menciptakan bagian dari mobil, tetapi dengan demikian pekerja tersebut akan mempunyai pandangan yang terbatas mengenai keseluruhan dari proses manufacturing mobil. Fokus nya adalah part yang dikerjakan nya saja. Mereka akan menganggap bahwa mobil tersebut merupakan kumpulan dari part yang sangat banyak yang bekerja secara bersama sama. Tapi tentu saja mobil itu lebih dari itu. Mobil yang baik tercipta dari visi. Dimulai dengan spesifikasi yang tertulis dengan baik. Kemudian design. Berbulan-bulan bahkan bertahun-tahun dihabiskan untuk design, mengubah, memodifikasi sampai mencapai kesempurnaan. Proses dari design ini tidak sepenuhnya dilakukan di atas kertas. Kebanyakan dilakukan dengan menggunakan model dari mobil dan melakukan testing dengan kondisi yang tertentu untuk melihatnya berjalan dsb. Design akan diperbaharui sesuai dengan hasil dari testing tersebut. Dan mobil pada akhirnya dikirim ke produksi, dan part dibuat kemudian digabungkan.
Software development juga sama dengan hal tersebut. Kita juga tidak boleh hanya duduk dan mengetik code. Kita memang dapat melakukan hal tersebut tapi hanya untuk kasus2 yang sederhana. Untuk software yg complex tentu saja tidak.

Untuk membuat software yang bagus kita harus mengetahui secara keseluruhan tentang apa software tersebut. Kita tidak akan mungkin dapat membuat software mengenai banking jika kita tidak mengetahui dengan baik apakah banking itu. Kita harus mengetahui domain dari banking tersebut.
Tidak mungkin membuat software banking tanpa memiliki domain knowledge yang kuat. Jadi siapa yang paling mengetahui domain tersebut. Tentu saja bukan soft architect, analyst, atau bahkan programmer. Tentu saja bankers. Tidak ada yang akan lebih mengetahui mengenai suatu sistem daripada orang yang bekerja di sistem tersebut. Orang dalam. Dimana hal tersebut merupakan makanan sehari-harinya. Mereka sudah pasti ahli mengenai hal2 detil yang terjadi dengan spesialisasi mereka. Kemungkinan2 yang terjadi dan segala jenis peraturannya. Dari sinilah sebenarnya kita harus memulainya. DOMAIN.
Ketika permulaan project, fokuslah ke domain. Karena fokus dari software adalah menambahkan kemampuan (otomatisasi) dari domain tertentu. Jadi domain dan software haruslah memiliki hubungan yang harmonis. Karena apa ? Karena memang untuk itulah software diciptakan. Mengatasi permasalahan yang ada di domain. Jika tidak maka software itu hanya akan menyebabkan bencana pada domain. Berlawanan dengan tujuan diciptakan nya.
Bagaimana membuat software harmonis dengan domain? Caranya adalah membuat software yang merefleksikan domain tersebut. Jadi konsep2 dan elemen2 yang ada di domain haruslah terdapat pada software tersebut. Begitu juga dengan relasi antara elemen2 nya. Software haruslah memodelkan domain.
Seseorang tanpa pengetahuan ttg banking seharusnya dapat belajar banyak hanya dengan membaca code dari domain model. Hal ini merupakan hal yang penting. Software yang tidak memiliki akar yg tertancap kuat ke domain tidak akan dapat mengatasi perubahan2 yang terjadi. Karena domain pasti akan selalu berubah. Perubahan merupakan hal yang pasti terjadi pada software development.
Jadi mulailah selalu dengan domain. Kemudian ???
Domain merupakan sesuatu dari dunia ini. Gak bakalan bisa langsung diambil dan diketik dan langsung jadi code. Mustahil. jadi kita harus bikin abstraksi dari domain tersebut. Dengan hanya mengambil hal2 yang penting2 saja dan mengabaikan hal2 yang bukan merupakan concern dari pengamatan. Dengan berbicara dengan domain expert kita akan belajar banyak tentang domain tersebut. Klo ingin bikin software accounting makan domain expertnya adalah accountant. dst. Tapi ketika kita berbicara dengan mereka yang kita dapat hanyalah pengetahuan2 mentah. Dan ga mudah diubah ke software kecuali kita bikin abstraksinya atau blueprint nya di otak kita. Bluerprint di awal pastilah tidak selalu lengkap. Tetapi seiring dengan waktu kita akan selalu memperbaikinya sama seperti mobil yang dibuat modelnya , ditest dan kemudian diperbaharui. Tapi model tersebut semakin lama akan semakin jelas.
Apakah abstraksi itu ? Apakah itu model, model dari domain ?
Domain model bukanlah diagram yang tertentu. Yang terpenting adalah ide yang dikandung oleh diagram tersebut. Karena diagram tersebut adalah tools. Jadi hanya alat untuk berkomunikasi saja. Juga bukan hanya mengandung pengetahuan dari kepala si domain expert. Tetapi sudah terorganisasi dan terseleksi dalam bentuk abstraksi dari pengetahuan si domain expert. Diagram digunakan untuk mengkomunikasikan model. Sama seperti code yg tertulis dengan baik. Sama dengan bahasa yang baik.
Model merupakan representasi dari domain yg kita amati. Dan sangat penting di dalam design dan proses development. Selama design kita akan membutuhkan banyak model. Karena dunia di sekitar kita terlalu banyak dicerna oleh otak kita yang kecil. Bahkan untuk satu domain saja otak seorang manusia gak bakalan bisa mengelolanya pada satu saat. Jadi kita perlu menyusunnya, membagi2nya menjadi bagian2 yang kecil, dan mengambilnya satu demi satu untuk diselesaikan. Domain mengandung banyak sekali informasi yang harus dimasukkan semuanya ke dalam model. Jadi kita harus memutuskan apa yang harus dimasukkan ke model kita apa yang harus dibuang. hal tersebut merupakan bagian dari design. Contohnya . Software banking akan menyimpan informasi mengenai alamat dari customer. Tapi tidak akan menyimpan warna dari mata customer. Ga ada gunanya bukan. Tapi jika kita bikin softaware dimana domainya adalah pencarian orang atau di kepolisan. Hal itu mungkin akan disimpan. Jadi tergantung dari domainya.
Model merupakan hal yg penting dalam software design. Kita membutuhkan nya untuk mengatasi kompleksitas. jadi hasil dari proses berpikir kita tentang domain kita tuangkan dalam bentuk model. Sehingga hal tersebut dapat kita review dan kita komunikasi kan dengan orang lain, domain expert, programmer, etc. Ga bakalan guna kita capek2 mikirin kalo ga bisa dijelaskan ke orang. Karena bukan hanya kita sendiri yang akan mengerjakan software tersebut. Banyak cara untuk melakukannya. Bisa dengan gambar, diagram, use case, lukisan, graphic, dll. Bisa juga dengan tulisan. Tuliskan ttg visi kita terhadap domain tersebut. Yang lainnya adalah bahasa. Kita dapat dan seharunya menciptakan bahasa yang dapat digunakan untuk mengkomunikasikan hal2 yg spesifik mengenai suatu domain. Intinya adalah kita perlu mengkomunikasikan model.
Ketika model sudah berhasil dibuat, kita dapat memulai dengan code design. Hal ini berbeda dengan soft design. Soft design dapat diibaratkan dengan membuat arsitektur dari rumah, mengenai gambaran kasarnya. Code design sudah berbicara mengenai detail, seperti lokasi dari lukisan pada dinding tertentu, motif dsb. Soft design lebih penting dibandingkan dengn code design. Karena lebih mudah memperbaiki error code design dibandingkan dengan error dari soft design. Costnya lebih murah. Tapi produk final juga tidak akan bagus tanpa code design yang baik. Oleh karena itu code design pattern membantu kita membuat code yang bersih dan mudh dimaintain
sumber:https://weltam.wordpress.com/2009/01/04/first-post/

Tidak ada komentar:

Posting Komentar