Kenapa perlu elakkan Anemic Domain Model

Salam

Aku sebelum ini percaya Anemic Domain Model tidak bagus jika ada dalam sesuatu domain model design/code dan aku masih lagi percaya cuma kini terdapat sedikit perbezaan dengan apa yang aku buat dalam sotware project terbaru. Ianya berkisar kepada "What System DOES" dan "What system IS". So anemic domain model nie hampir definasi apa yang dikenali "What system IS". Daripada Martin Fowler, symptom Anemic Domain Model ialah

"The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data".

Aku semakin slow dalam coding dan semakin slow juga nak faham code, so kalau code yang terlalu banyak tempat business algorithm dimana aku kena refer pada object A dan kemudian pergi ke object B, menjadikan aku kurang efficient so tak 1Malaysia lah cam nie. 1Malaysia pencapaian diutama so begitu jugalah halnya dalam code, code yang senang dibaca dan efficient sangat2 diperlukan, tapi ini semua abstract. Mungkin senang bagi developer Najib (bukan nama sebenar) tidak mudah untuk developer bernama Anwar (pun bukan nama sebenar). Cuma kita boleh ambil tahap pertengahan dimana indicator yang dirasakan setiap developer tu boleh memahami at least 60%-70% code yang awal apabila diberi code untuk dibaca.

So aku sudah pun bermula dengan pecahkan object2 aku kepada 2 bahagian. Basic object ialah ada attribute dan ada behaviour. So sekarang object2 aku buat dah seakan kembali menjadi anemic domain model percayalah. Cuma perbezaan dengan symptom anemic domain model sebelum ini ialah object attribute dan behavior tidak akan bersatu dan sebaliknya object lain dikenali sebagai "services" yang akan memainkan peranan menGALAS tanggungjawab untuk melakukan perbuatan baik dan buruk (method/behaviour object ada buruk dan baik gak). So yang macam nie memang aku bangkang. Aku tak boleh terima sesorang yang ada maklumat tetapi yang akan buat kerja orang lain berdasarkan maklumat tersebut. Jadi apa yang aku perlukan ialah di masa design code aku dipecahkan tetapi pada masa runtime atau pada masa diperlukan aku boleh dapat behavior2 tersebut. Itulah bezanya "runtime".

So aku boleh reuse behavior tu kepada mana-mana object yang perlu. Ambil contoh mudah

Manusia (Person) ada Nama Rasmi dan Nama panggilan, so aku ada satu satu behaviour yang cantumkan nama rasmi dan nama panggilan untuk return string. Jadi behaviour tu aku boleh pakai re-use kembali pada mana-mana object yang mempunyai structure contract yang sama. Orang yang biasa dgn OOP maybe dah terbayang untuk membuat satu interface dan ada class yang implement tapi bagi aku yang macam nie susah. Aku inginkan cara yang lebih mudah dan fluent.


class Orang
{
string Nama;
string Panggilan;
}

class Kereta
{
string Name
string Code
string Panggilan;
}

Maybe ada suggestion untuk buat interface dan setiap object tu implement interface, tapi bagi aku cara nie panjang macam code kat bawah ni.

interface Cantum
{
string CantumNamaPanggilan(string name,string panggilan);
}

class Orang :Cantum
{
string CantumNamaPanggilan(string name,string panggilan)
{
///
}
}

class Kereta : Cantum
{
string CantumNamaPanggilan(string name,string panggilan)
{
///
}
}

Dan mungkin ada yang suruh letak implementation dalam abstract class, cuma bagi aku limitation class hanya boleh extend pada satu abstract class, kalau ada bnyk behavior takan nak letak semua dalam abstract class tu. Ada cara lain tak yang aku tak nampak sebelum aku bagi cara yang aku cuba nak buat (belum diuji tahan peluru dan api :)?

DDD : Messaging

Konsep messaging banyak digunakan dalam DDDD atau dikenali sebagai Distributed Domain Driven Design. Dalam .Net community setahu aku ada 2 transport application iaitu NServiceBus dan MassTransit. Cuma messaging approach boleh juga digunakan dalam cara Domain Driven Design yang biasa tanpa menggunakan any messaging transport.

Aku tertarik dengan konsep messaging dari segi kekemasan code dan keupayaan code tersebut bila didesign ala messaging. Kalau mengikut DDDD, Domain akan reference/couple dengan messaging structure manakala jika follow DDD, service akan reference/couple dengan messaging structure.

Dalam post kali nie aku nak bawa contoh bagaimana hendak guna DDD dengan messaging iaitu service reference messaging structure.

Aku baru je nak mencuba, so kalau silap bagi tahu.Apa itu message? Kalau ditanya kepada aku apa itu message jawapannya ialah satu set yang mengandungi samaada arahan atau maklumat sesuatu Context. Sebagai contoh context Tunjuk jalan ke Masjid Shah Alam. Maka terdapat arahan dan maklumat yang perlu letakkan didalam message untuk di hantar kepada si penerima. Penerima boleh jadi rakan sekerja, pemandu teksi atau sesiapa yang faham message tersebut. Berdasarkan message tersebut si penerima akan response berdasarkan apa yang diminta dan supporting maklumat.

Message : Tunjuk Jalan Ke Masjid Alam

Arahan : Sila bagi arahan untuk Ke Masjid Shah Alam
Maklumat 1 : Aku sekarang di lokasi seksyen 9 dan destinasi Masjid Shah Alam
Maklumat 2 : Aku nak pergi menaiki kereta

namespace Direction.Services
{
    public interface IMessage
    {
    }

    public interface IServiceHandler<TMsg> where TMsg : IMessage
    {
        void Handle(TMsg msg);
    }


    public class TunjukJalanKeMasjidShahAlamMenggunakanKereta : IMessage
    {
        public string from { set; get; }
        public string to { set; get; }
    }

    public class TunjukJalanKeMasjidShahAlamBerjalanKaki : IMessage
    {
        public string from { set; get; }
        public string to { set; get; }
    }

    public class TunjukJalanKeMasjidShahAlamMenaikiBasikal : IMessage
    {
        public string from { set; get; }
        public string to { set; get; }
    }

    public class DirectionService :
        IServiceHandler<TunjukJalanKeMasjidShahAlamBerjalanKaki>,
        IServiceHandler<TunjukJalanKeMasjidShahAlamMenggunakanKereta>
       
    {
       
        #region IShowDirection Members

        public void Handle(TunjukJalanKeMasjidShahAlamBerjalanKaki msg)
        {
            //Send to Domain to calculate and show the possible way
            //Direction.FindFrom(msg.from).FindTo(msg.to).With(Transportation.Leg);
        }

        public void Handle(TunjukJalanKeMasjidShahAlamMenggunakanKereta msg)
        {
            //Send to Domain to calculate and show the possible way
            //Direction.FindFrom(msg.from).FindTo(msg.to).With(Transportation.Car);
        }

        #endregion

      
    }
}

Code diatas tidak di test dan hanyalah imiginasi sahaja untuk tatapan umum.

DDD : AggregateRoot rules

Salah satu pattern yang tersangat penting dalam Domain Driven Design ialah AggregateRoot. Dan ianya juga adalah pattern yang nampak mudah tapi susah untuk di pilih semasa didesign di dalam Domain Model.

Apa definisi AggregateRoot? Kalau mengikut buku Domain Driven Design dan setelah membacanya aku boleh membuat kesimpulan pemahaman aku sendiri yang pada aku betul, iaitu AggregateRoot ialah anda mengroupkan beberapa entity atau value object kepada sesuatu object entity yang akan menjadi ketua dan object entity ini akan bertindak menjaga sebarang anasir-anasir baik dan jahat dari luar yang menganggu kelompok/komuniti. Ini bermakna jika ada permintaan dari pihak luar yang bukan penduduk dalam komuniti AggregateRoot tadi maka permintaan tersebut perlulah melalui ketua tadi dan si ketua yanag akan memanggil pengikutnya (Aggregate) untuk bertindak dan tindakan yang berlaku adalah diketahui oleh siketua. Ok ini bahasa mudah yang aku nak cerita, bahasa susah korang google lah sendiri.

Kepentingan AggregateRoot jika di design dengan betul, akan mengurangkan keserabutan (complexity).

Rule yang pertama aku follow, developer lain ada rules masing-masing mengikut pemahaman dia orang. Aku pun baru je faham tu pun kekadang salah pilih AggregateRoot. Lagi satu peringatan jika kesilapan memilih AggregateRoot boleh menjadikan design anda menjadi lebih komplex dan aku pernah merasa keperitan ini. Aku akan hanya pilih AggregateRoot bila perlu dan jika tidak perlu aku tak nak buat. Ianya bukan kemestian, cuma memastikan kekuatan design. Sebelum ini 2/3 bulan sebelum ini pemilihan aggregate root macam kemestian tapi apabila dah terjerat baru kutahu langit itu tinggi. Walaupun dari segi turutan dalam design domain model priority AggregateRoot ialah ketiga penting setelah mengenal pasti entity/value object (1) dan relation association antara object(2). Ianya berada ketangga ketiga hitz sepanjang zaman volume 1 kompilasi, tapi kekuatan design banyak berkait rapat dengan AggregateRoot.

Rule aku yang kedua, Aggregate ialah rakyat marhaen dibawah jajahan takluk AggregateRoot. Jika delete AggregateRoot, maka semua Aggregate akan turut sama terkorban dan mengorbankan diri (kes ikut ketua tanpa usul periksa U jump, I jump) mereka ini tidak nak menjadi anak yatim piatu. Dalam erti kata sebenar Aggregate ini tidak bernilai jika tidak bersama-sama AggregateRoot dan mesti ingat nilai ini adalah berdasarkan Context. Contoh nilai berdasarkan context ialah jika anda masuk kekedai Kereta sama ada baru atau terpakai (second hand) , tujuan anda ialah hendak membeli Kereta itu ialah Context, maka bayangan anda ialah sebiji kereta yang normal yang lengkap dengan body, engine, interial dan tayar. Apa perasaan anda jika hendak beli kereta tapi oleh kerana bodynya tidak dijual dan yang dijual hanyalah tayar apakah nilai tayar dalam context awal tadi. Salesman tu mungkin kena baling dengan tayar tu kot. Tapi sebaliknya jika anda dah ada sebuah kereta tapi tayar anda bocor dan perlu diganti, maka jika anda pergi ke kedai service kereta, mekanik tu akan ganti tayar anda bukan ganti kereta anda, disini tayar adalah lebih bernilai mengikut context tayar bocor.

Rule yang ketiga, sebarang kerja yang dilakukan oleh aggregate , maka AggregateRoot perlu memantau agar perkara-perkara tidak senonoh tidak berlaku dalam jagaan dia. Ok ambil contoh Mursyidul Am PAS ialah AggregateRoot bagi Aggregate jemaah PAS, maka sebarang aktivi seperti Unity Goverment ke atau apa, beliau kena tahu dan tegur jika ada pelanggaran berlaku yang merugikan Islam dan Parti, Aggregate tidak boleh buat sesuka hati nak berdua-duaan dengan orang lain. Orang lain dari luar parti perlu berbincang dengan Mursyidul Am PAS kenapa perlu berdua-duaan untuk kebaikan ummah ke atau apa ke. So jika bukti keikhlasan maka Mursyidul Am PAS mugkin ada letak syarat jika anda ingin kawan dengan si Aggregate A dari Terengganu maka syaratnya Islam mestilah didahulukan dan lain-lain syaratnya. Pendekkan cerita katakan lah Mursyidul Am PAS setuju dan berkawanlah si orang luar tadi dengan Aggregate A, dia pun suruh lah bermacam-macam, suruh buat ini dan buat itu dan semasa perkerjaan tersebut dibuat semua informasi tersebut dipantau terus oleh Mursyidul Am PAS dan tiba-tiba dilihatnya orang luar itu suruh Aggregate A menari ronggeng, wah nie dah kes berat , berdasarkan syarat yang dipersetujui maka terdapat pelanggaran syarat maka perkerjaan Aggergate tadi akan dihentikan dan timbul Pop Up Message "Tak Takut Allah ke hehehehe ". Maka tugas AggregateRoot tadi menjaga supaya tidak tercemar Agregate-Agregate yang berada dibawahnya.

Kesimpulan 3 rules yang aku rasa paling hitz yang boleh dijadikan panduan memilih bakal AggregateRoot, walaupun ada rules lain tapi tidak sepenting rules2 ini. Cerita yang dibawa tiada kena mengena dengan yang hidup atau yang mati dan tiada kena mengena dengan isu sekarang.

Selamat beraggregate root - jangan nak rongeng2

Kenapa ERD tidak boleh express real world problem

Sebelum ini, lama dahulu semasa zaman muda-muda, sebagai programmer yang bersemangat waja apabila mendapat sahaja tugas untuk develop software/aplikasi tidak kisahlah yang besar atau yang kecil atau mewarisi aplikasi itu untuk dijaga dari senior programmer, maka perkara pertama bermain di benakku ialah bagaimana rupanya database design, berapa banyak table dan lain-lain yang sewaktu dengannya.

Aku cukup suka bila semua relation dalam database lengkap dengan primary key, foreign key, constrains dan aku rasa bila database dah complete baru aku ready untuk buat coding. Dulu memang aku tak dapat nak bayangkan macam nak memulakan coding applikasi yang berkaitan dengan penyimpanan maklumat tanpa perlu memikirkan database design. Bila bercerita dengan customer aku akan bayangkan database design bila bercerita dengan team se unit pun bercakap pasal database design.

Berbalik semula 7 tahun lepas aku kenal mamat H nie, olahan cerita beliau tentang software development approah mengusik akal fikiran ku. Aku terasa ajaran beliau berlainan tidak seperti yang biasa aku dan kawan-kawan aku buat dan fikirkan. Tentang konsep design pattern, pertama kali dengar :) ialah aku budak electrical yang banyak aku dengar semua berkaitan dengan electrical term. Jadi aku terus tumpukan perhatian pada setiap posting beliau dan aku juga kerap kali bertanya soalan. Oleh kerana begitu berminat dangan cara beliau aku pernah ambil beliau naik motor kapchai aku bawak datang ofis minta dan tunjukkan pada beliau apa yang aku buat, dia tegur aku jagan fikirkan pasal database design aku masih lagi tidak boleh lari dari terus terbayang akan si database design nie, penagangan database design aku rasa cukup kuat, dan aku pasti ramai yang ada perasaan tersebut walaupun dah capai umur baligh dalam programming :)

Aku cuba lagi, dan aku diperkenalkan pula dengan Peter Coad teknik - Colour Modeling, selepas mengodek-godek cara tersebut barulah ada sinar FM sikit pada cara aku berfikir. Aku sudah boleh melupakan sedikit si database design. Aku join group color modelling dan banyak soalan bodoh aku tanya dalam group tu.. arghh buat apa aku nak malu, dia orang bukannya nampak muka aku masa aku tanya, dah lah english aku cukup makan nak tanya pasal design level enterprise lak tu.. hahahaha. Yang bagusnya ramai jugak lah response pada pertanyaan aku, aku oleh kerana excited sangat selepas siap je buat design class terus pergi Cyber Cafe dah malam dah masa tu tapi dia orang kan siang so dapatlah jawapan segera bila dia orang review example tersebut.. pergh seronok betul, betul, betul

Selepas tu nie aku tak ingat macam mana aku boleh beli buku Domain Driven Design, sama ada mamat M bagi tahu aku atau pun aku terbaca dalam forum tersebut. Buku nie aku baca lebih dari sekali dan ambil masa untuk aku faham.

Ok aku dan lari jauh dari tajuk yang aku nak cerita. Aku nak bagitahu pada mereka yang masih lagi berfikir tentang database design, cubalah ambil masa fikirkan cara alternatif sikit.

Aku nak bawa contoh yang biasa-biasa aje, Customer membuat Order untuk membeli beberapa barang keperluan. Ok untuk simple case kita akan ada object Customer, Order dan OrderLine

Kalau kita buat database design dia akan jadi macam nie kan



Relation antara Customer kepada Order adalah sama dengan relation antara Order dan OrderLine. Tapi kalau mengikut design sebenar mengikut comman senario ianya bukan begitu.

Customer dan Order ialah unidirectional association, bermakna Customer tidak perlu tahu tentang Order, sebaliknya Order tahu akan Customer.

Manakala untuk Order dan OrderLine relationnya pula bidirectional, bermakna Order mempunyai maklumat tentang OrderLine dan begitu juga sebaliknya OrderLine mempunyai maklumat tentang Order.

Tapi relationnya tiada beza, bagaimana? satu unidirectional dan satu lagi bidirectional, jadi bagaimana. Perkara tersebut hanya boleh di terangkan dengan design domain model menggunakan UML. Berdasarkan design ini kita boleh terangkan OrderLine lifecycle dia dependecy kepada Order, kalau kita listkan semua maklumat OrderLine pun tiada guna kerana maklumat tersebut hanya berguna bila disekalikan dengan maklumat Order. Untuk Customer bukan tugas Customer untuk tahu semua maklumat Order, apa yang Customer perlu tahu jika diberi maklumat Customer sistem perlu bagi maklumat Order kesemua Order yang di lakukan oleh Customer tersebut.




Selamat mencuba dan Vote No to BIJAN