Cost dari membuat message

Disarikan dari blog greg young.

Dengan membuat aplikasi yg berkomunikasi via message pasti akan banyak tipe message yg akan dibuat. Apakah kita akan mempermasalahkan waktu untuk membuatnya ketimbang dengan scalability nya. Greg young membantah pernyataan bahwa untuk membuat message ini membutuhkan waktu lama. Saya setuju dengan pendapat greg karena kok masalah kecil seperti itu yg dibahas. Jelas maslah tersebut tidak terbandingkan dengan keuntungan yg didapat.

Emang dengan membuat aplikasi dengan tipikal Command Query Separation dan messaging maka tipe akan menjadi lebih banyak. Tetapi coba bandingkan dengan traditional arsitektur. Dimana scalability sulit dicapai dan performance rendah. Jelas bukan hal yg bisa dipertandingkan.

Yah dengan arsitektur tempo dulu dengan RPC maka kita berkomunikasi dengan DTO. Data Transfer Object. Hanya data saja. Dengan messaging jelas menjadi lebih banyak karena message tersebut mengandung behaviour yg akan terjadi dan membawa keterangan mengenai operasi apa yg terdapat di server. Jadi emang jelas jadi makin banyak. Bukan hanya sekedar data saja yg dibawa oleh message tetapi juga behaviour terhadap data tersebut.

Nah di sini greg young juga kelihatannya agak kecewa juga dengan pendapat miring seperti itu yg mempersalahkan masalah waktu membuat message. Klo saya menterjemahkan nya seperti ini dalam bahasa saya. “Ah kok yg ga penting pula dipikirin, masih ada yg lebih penting dari situ”. Dia juga menekankan bahwa ya udh lah.. klo ga mw cape2 ya ga ush pake DDD. Pake code generation aja. Hahaha. Kelihatannya si greg itu udh gondok liat yg kasih kritik.

Nah juga dengan CQS kita juga akan membuat tambahan layer baru disbanding dengan DDD style versi RPC. Mmm…. Saya bahas dulu mengenai arsitektur DDD versi RPC. Ini yg sekarang lagi kami pakai. Pada sisi Server terdapat Domain layer sesuai dengan DDD inilah tempat dimana model hidup. Repository untuk mengurus life cyle dari Entity. Bahasa kampungnya adalah repository ngurus operasi2 apa saja yg dapat dilakukan terhadap aggregate root dari entity tertentu. Nah juga ada service layer dengan menggunakan .NET Remoting.

Nah arsitektur yg sekarang banyak operasi read dan write yg tidak dipisah. Karena apa ?? Agar tidak bolak balik nanya ke server. Alias agar tidak chatty. Dan juga untuk operasi read misalkan client meminta sesuatu dari server harus melalui repository dan mengembalikan entity dan kemudian entity diubah mejadi DTO oleh assembler. Wah… padahal hanya untuk read aja kok repot banget ?? Padahal kan hanya operasi baca. Tidak ada bisnis logic di sana. Emang sih udh ada yg dioptimasi dengan menggunakan query HQL NHibernate sehingga langsung aja mereturn DTO. Tapi menurut saya hal ini sudah menyalahi aturan repository. Ato mungkin saya aja yg sok tw repository itu apa ya ? ahahhhahhah

Nah dengan CQS. Command dan Query itu dipisahakan. Operasi untuk nanya ya hanya untuk nanya alias read. Yang untuk command atau write ya hanya untuk itu. Si greg lebih membuatnya tajam lagi dengan membedakan proses baca dan tulis. Jadi untuk write baru berhubungan dengan domain. Ketika untuk baca ya pake layer tersendiri yg namanya read layer. Jadi ini hanya thin layer untuk akses ke persistence storage. Dan disesuaikan dengan keinginan dari UI atau report. Jadi sekarang masalahnya ada dimana kita menempatkan code untuk reading apakah itu di repository atau ada model lain untuk reading.
Udi dahan membuat database yg terpisah juga untuk operasi read dan write dan ada juga proses sinkronisasi. Tapi itu tidak saya bahas di sini.

Tapi mungkin biaya yg kita lihat di sini maksudnya biaya adalah kerjaan2 yg nambah. Hehehe. Emang jadi banyak kerjaan sih. Tapi jangan hanya lihat dari satu aplikasi aja. COba perhatikan juga gimana maintain antar aplikasi dan yg lain. Nah jaman skarang ini mana ada lagi aplikasi yg hanya berdiri sendiri atau menyepi. Semuanya udh saling terkoneksi.

Jadi sekarang interaksi antar aplikasi sudah sangat complex dan rumit. Contohnya Point Of Sales berhubugan dengan Accounting Context dan ke Warehousing Context. Warehousing Context komunikasi dengan Inventory Context dan Accounting Context. Accounting context ke Warehousing context dan …. Okelah lanjutin sendiri. Intinya ya ga bisa berdiri sendiri saja. Agar fungsionalitas tercapai juga butuh komunikasi antar yg lain meskipun tetap harus otonom.

Biasanya orang ngabisin uang banyak2 untuk bikin aplikasi2 bisa saling komunikasi tidak memikirkan dari awalnya. Nah sebenarnya kita harus mikirin masalah integrasi dari awal. Jadi dengan system yg sifatnya message base kita dapat lebih menggabungkannya menjadi lebih mudah. Karena emang tinggal colok aja dan jalan.

Integrasi yg paling sering terjadi pada aplikasi dengan arsitektur yg traditional adalah integrasi pada level database. Main tembak langsung aja ke database. Mengerikan. Ini harus dihindarkan. Nah jadi jika kita tidak mw melalui data maka kita harus kirim pesan aja. Jadi pikirkan dari awal tentang messaging. Jadi emang awalnya sulit dan bnyak yg mw dikerjakan tetapi ketika integrasi ga ada lagi masalah2 conflict2 seperti mapping hibernate yg gagal atau field tidak ada atau yg aneh2 lain.

Advertisement