SOC Application - Make it simple

Saya dapat beberapa feedback dari member satu office yang terlibat dalam project nie, design model saya sebelum nie dah masuk part yang agak complex , so saya fikir saya perlu jadikan design tersebut lebih simple (KISS) "Keep It Simple Stupid". Kemungkinan ada yang dah biasa dengar KISS punya cara atau kalau dari XP (Extreme Programming) "Do the simple thing that could posibble work".

Ok berbalik semula kepada SOC Application, bila saya review balik design model saya..memang saya perhatikan saya dah terover design pada peringkat awal, dan perkara ini bukan nyer satu yang buruk tapi menjadi leceh sedikit bila masuk bab test.Jadi saya fikir saya perlu redesign semula design SOC model agar nampak lebih simple dan tambah complex dari masa kesemasa. Cuba ingat semula use case saya memang cukup simple iaitu unutk create new docket yang merekodkan sesuatu masalah yang berlaku di datacenter dan juga merekodkan product apa yang terlibat. Jadi apa masalah dengan design awal saya dahulu? Design awal saya dahulu diperingkat permulaan saya dah define a few business rules yang agak complex seperti ProblemSpecification. ProblemSpecification tidak perlu diletakkan dahulu kerana perkara pertama yang kita perlu lakukan ialah create Docket baru untuk DataCenter dan Product yang bermasalah.

Jom Modeling
Dari use case tersebut terdapat 3 entity iaitu
-Docket
-DataCenter
-Product

Entity yang lain yang agak tersembunyi ialah Location. Setiap DataCenter mempunyai Location, dimana didalam satu Location boleh ada 0..* DataCenter. Entity location akan lebih jelas apabila kita mula design model. Perlu diingat, kita boleh pada bila-bila masa untuk tidak memasukkan object-object yang apabila kita design menjadikan sesuatu menjadi lebih komplex.

Design awal model.



Dari gambar design model diatas, apa yang boleh kita ceritakan ialah Location boleh mempunyai 0,1 atau lebih Docket pada satu-satu masa iaitu one-to-many manakala pada view Docket pula ialah hanya boleh ada 1 Location pada satu-satu masa.Location juga boleh mempunyai 0,1 atau lebih DataCenter pada satu-satu masa dan DataCenter mempunyai 0,1 atau lebih Product dan begitu juga sebalinya.

Ini ialah UML Diagram bukan database schema, jadi design ini tidak menggambarkan bagaimana object akan di "persist" ke dalam database sebaliknya design ini menunjukkan bagaimana kelakuan aplikasi yang kita bina.

Ok dari design model ada part yang kita boleh improvekan lagi, perlu diingat bidirectional association menjadikan object bertambah complex.Perhatikan relation antara Docket dan Location. Location akan ada senarai Docket, tetapi adakah kita perlukan semua rekod Docket dari Location. Pada kenyataan memang Location mempunyai senarai Docket, tapi kita lebih berminat hendak mengetahui Location yang mana untuk specific Docket, jadi Docket mempunyai relation pada Location tapi bukan sebaliknya.

Lepas itu, kita tengok antara Location dan DataCenter, Location mempunyai one-to-many dengan DataCenter, adakah kita hendak senarai DataCenter tanpa mengetahu dimana lokasi DataCenter tersebut? Tidak bukan, DataCenter tanpa context Location tak memberi apa-apa maklumat jadi DataCenter termasuk dalam Aggregate Boundry Location ini bermakna senarai DataCenter perlu dicapai melalui Location.DataCenter dan Product pula mempunyai hubungan one-to-many tapi yang penting DataCenter tahu Product apa yang terdapat dalam DataCenter, manakala maklumat Product mengetahui dimana ianya berada pada saya tidak penting dalam context Docket.

Dari perbincangan saya design model yang dapat saya buat adalah seperti dibawah.


perlu diingat kita boleh dapat 2 perspektif view design model dari keseluruhan process dan lagi satu apabila process create. Ok setakat yang kita bincangkan dan dari gambaran design model yang telah saya buat, design model yang ada merupakan gambaran dari view keseluruhan. Jika view create kita ambil kita perlu lihat ianya sebagai berikut.

Satu Docket akan akan hanya ada untuk satu Location dan merekodkan problem untuk satu DataCenter yang mengandungi satu Product yang bermasalah.Gambaran design untuk view dari perspektif create.



Seterusnya apabila kita dah dapat lihat dari view perspektif create dengan lebih jelas adalah mudah untuk kita memahami process seterusnya.Location,DataCenter dan Product merupakan object-object yang kebiasaanya mempunyai value, ini bermaksud bila kita hendak create Docket, value Location,DataCenter dan Product bukannya dapat dari process create Docket sebaliknya ia adalah dari process Admin Management. Kita hanya perlu dapatkan value tersebut dari Relational Database,FileSystem atau Storage System.Ok jadi disini saya akan create satu Repository untuk dapat value-value Location,DataCenter dan Product. Dari design yang kita buat calon untuk kita adakan Repository ialah pada Location.Repository hanya ada pada Aggregate Root sahaja.



Apa yang anda fikir, adakah design ini boleh mencapai objektif use case kita? Saya tidak kata domain model design yang saya buat ini betul, dan macam maner saya nak mengetahui domain model design ini ok?Saya nak supaya kita dapat berfikir sedikit dimana problem yang timbul dalam design model ini. Semuanya nampak okkan?

Sebenarnya masalah yang timbul ialah hubungan antara Docket dan Location, walaupun hubungan ini betul, tapi ini tidak dapat menjawab use case kita.
Docket merekodkan fault problem unutk product yang berlaku di dalam sesebuah DataCenter, manakala DataCenter pula berada dalam Location tertentu. Jadi kita perlu tukar sedikit design tersebut.Jadi Docket tidak perlu tahu tentang Location dimana berlaku fault , tapi Docket perlu tahu Product yang mana satu bermasalah. Jika Docket ingin tahu Location, ia boleh minta dari DataCenter dimana Location tersebut.Jika ingin menegtahui DataCenter boleh dapatkan dari Product.