Saturday, June 14, 2008

Menyadari Kesesatan Penggunaan Domain Model Pattern

Waktu diskusi terakhir tentang arsitektur framework software sama Harry dan Dankos, gw memulai diskusi masalah penggunaan model pattern di aristektur MVC yang kami gunakan. Martin Fowler menyebut model dalam MVC itu sebagai Domain Model pattern. Di diskusi itu kami diskusiin gimana seharusnya model itu diimplementasikan. Karena selama ini, logic aplikasi banyak terjadi di sisi controller atau DAO (kami pakai DAO untuk akses data). Hasil diskusi itu menyimpulkan perlu adanya perubahan.

Hari ini, lupa tadi nyari apa, tapi dapet artikel bagus banget. Tulisanya bisa dibaca di sini. Yang akhirnya di situ ada link ke tulisan Martin Fowler lagi, bisa dibaca di sini.

Martin Fowler (MF) membahas tentang anti-pattern yang namanya AnemicDomainModel. Anti-pattern adalah design pattern yang keliatanya benar tapi nyatanya jauh dari optimal jika digunakan. Anemic adalah salah satu anti-pattern.

Nah anemic ini yang ternyata selama ini banyaknya kami gunakan. Begitu juga di beberapa aplikasi yang orang lain buat yang gw pernah liat. Hmm, gw jelasin pake bahasa gw aja tentang anemic. Kalo mau baca penjelasan MF, liat di link tadi aja :)

Begini, di aplikasi yang terakhir kami buat, pada akhirnya model itu seperti struktur data struct (di C) atau type (di pascal). Model berisi kumpulan propoerty dan ada getter dan setternya. Tapi, behaviournya gak ada. Ataupun ada, hanya sedikit sekali. Business prosesnya ada di controller atau ada di DAO (banyaknya di DAO). Dan ada ganjelan di hati ini yang sangat luar biasa sekali disampaikan oleh MF di artikel itu.

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together.


Begitulah, ternyata slama ini gw sesat :)) Untuk mengungkap kesesatan-kesesatan yang lain, dan memperbaikinya. Sekarang lagi baca dua buku tentang pattern, Head First Design Pattern dan Patterns of Enterprise Application Architecture (Martin Fowler). Untuk liat pattern-pattern Enterprise Apps punya MF bisa diliat di sini.

Saran buat yang sama-sama sesat, baca buku Patterns of Enterprise Application Architecture di situ, ada penjelasan berikut contoh tentang penggunaan Domain Model pattern.

9 comments:

wildabdat said...

PERLU BANYAK TAUSIAH DARI USTAD APPLICATION DESIGN CONCEPT :)

Akhmad Fathonih said...

Hati2, too many patterns will kill you;) hahaha,gw aja kali yg blm bnyk pake pattern..:p

Anonymous said...

rrrr
saam ... saam ...
katanya mo ngirimin ibuk jadi ndak ?

Isaam Khalid said...

eh, ris lupa nih. ebook yang judulnya apa ris?

Anonymous said...

Asal jangan sesat lagi menyesatkan, sam ;D

Iya, ternyata kita (kita?? kata si isaam, lo kali jar) sering tersesat selama ini....

Ditunggu sam, tulisan-tulisan nya tentang patterns.. semoga suatu saat bisa nyusul hehe.

Anonymous said...

@akhmad fathonih:
pattern yg mana sih? kalo misal kita memakai kebiasaan kita berulang2, apakah tidak berarti kita pake pattern juga? :D

Isaam Khalid said...

@akhmad fatonih:
pake mas, cuman ga berasa :D

@yogatama:
bisa aja mas, jadi Yogatama Pattern :) hehe.

Anonymous said...

Berdasarkan artikelnya Sean A Corfield itu,
salah satu penyebab anemicnya adalah karena business logicnya berpindah ke service layer.

Tapi ketika kita ingin meletakkan business logic di domain model itu sendiri, terkadang muncul masalah ketika logika business melibatkan beberapa model, dimana jika logika business itu tidak ditaruh di luar model itu, akan menimbulkan "dependensi yang tidak semestinya (dependensi yang terbalik)" antar model. Kalo kasusnya kayak gitu gimana saam? Logic business kan di luar model (ada di service layer).

Uudashr said...

Mungkin saatnya befikir sesuatu itu gak dari data-nya dulu. Klo berfikir secara data nanti jadinya struct, atau class yang isinya getter and setter doangan. Mari kita ubah cara berfikirnya.