SOC Application - Analisa Domain

Artikel sebelum ini:
SOC Application - Requirement

Sebelum ini saya pilih solution proposal 2. Pada saya proposal 2 lebih jelas menerangkan kepada saya apa yang berlaku. Untuk saya buka sesuatu docket saya perlukan ProblemSpecification dimana ianya mempunyai maklumat tentang dataCenterName dan productName mungkin juga mengandungi beberapa maklumat yang lebih complex seperti startFaultTime, manakala DataCenterProduct pula merekod senarai Product yang terdapat dalam DataCenter.

ProblemSpecification menerangkan matlamat Docket, tanpa ProblemSpecification, Docket akan menjadi complex dan agak susah untuk diubah.



Untuk maklumat sesiapa yang datang dari backgroud database design, cuba ignore pasal database pada tahap ini.Anda mungkin akan bercelaru jika pada tahap ini anda bayangkan design tersebut dalam bentuk Database design.

Entity Dan ValueObject
Sekarang saya fikir untuk pergi ke langkah seterusnya, saya detailkan lagi association antara domain-domain tersebut. Docket akan ada one-to-one relation dengan ProblemSpecification. Problem Specification ialah ValueObject dimana saya hanya berminat dengan value DataCenterName dan ProductName dan beberapa maklumat lain.Jika terdapat docket yang mempunyai problem yang sama, jadi ProblemSpecification boleh dikongsi antara docket.Kebiasaanya ValueObject tidak boleh diubah jika ianya di kongsi dengan docket-docket yang lain. Jadi anda perlu analisa samaada ProblemSpecification boleh dikongsi atau tidak. Untuk makluman saya design ini secara terus dari requirement yang ada dan sambil menulis artikel, jadi anda dapat lihat process sebenar design iaitu adakalanya akan ada pertukaran semasa dalam process tune design.

Docket adalah entity, setiap docket perlu dibezakan antara satu sama lain dan perbezaan docket ini ialah di docketNumber atau docketTicket.DataCenter dan Product kedua-dua ialah entity, kita kenali kedua-dua entity melalui dataCenterCode dan productCode.

Aggregate
Ditahap ini, saya masih lagi memerlukan tune pada design domain, Ok kita tumpukan pada 2 domain, DataCenter dan Product. Disini kita memerlukan Root Aggregate, iaitu point access, dimana domain diluar aggregate boundry hanya boleh mempunyai reference pada Root Aggregate, Aggregate akan memudahkan reference antara domain supaya tidak menjadi complex.Domain hanya perlu satu point access untuk mendapat maklumat domain lain yang berada dalam aggregate boundry.

Seperti contoh kalau kita hidup berjiran, kita tidak boleh tahu kesemua maklumat dalam rumah jiran kita, yang kita perlu kenal ialah ketua rumah tersebut dan dari situ kita boleh dapat maklumat lain seperti berapa orang anak beliau. Jadi ketua keluarga tersebut yang akan menjawab.Lagi satu contoh anak kita berkawan dengan anak jiran, dan pada satu hari ada kelas tambahan, kita minta supaya anak jiran dapat pergi kesekolah dengan anak kita, jadi kita akan pergi kepada jiran kita (ketua keluarga) dan minta pada beliau agar anak beliau dapat pergi kesekolah dengan anak kita. Beliau yang mempunyai hak keatas anak beliau. Ini antara contoh Root Aggregate dan Aggregate Boundry.

Berbalik pada DataCenter dan Product, dalam context docket, kita setuju DataCenter dan Product adalah entity, perlukah kita wujudkan aggregate antara kedua-dua entity ini? Adakah kawalan khusus antara kedua-dua entity tersebut? Ya terdapat kawalan khusus iaitu senarai product berdasarkan DataCenter. Kita tidak berminat pada product tanpa mengetahui DataCenter dimana product itu berada.Jadi saya pilih DataCenter adalah Root Aggregate dan Product adalah aggregate boundry. DataCenterProduct merupakan ValueObject jadi ianya tiada masalah berada dalam aggrete boundry tersebut.