DDD rules diguna hanya pada Command process

Apabila design domain model menggunakan Domain Driven Design pattern seperti Aggregate Root, Service , penggunaan pattern ini hanya valid pada process yang melinatkan command sahaja. Pattern ini pula dikenali sebagai CQS - Command Query Separation (Arhitecture Level). Jadi untuk list/search atau reporting rules DDD tersebut tidak diguna pakai. Anda free untuk search dari mana-mana entity.

Keperluan melakukan refactoring

Refactoring dikategorikan sebagai seni, sama juga dengan Domain Design, memerlukan kreativiti dan kesabaran untuk mendapat keputusan yang bagus.

Kebiasaan Refactoring session boleh berlaku 3 -4 kali sebelum anda mendapat keputusan yang terbaik.

Refactoring yang selamat jika pada permulaan design dan conding, enviroment development sudah bermula dengan Test Driven Development (TDD).

Maka jika berlaku major perubahan pada code dan design, kita tidak perlu risau dependency dengan code/component lain insyAllah dengan cepat dapat di ketahui jika berlaku error.

Message boleh jadi Command atau Event

Bila buat naming method menggunakan message sebagai parameter ada 2 jenis message yang boleh digunakan

1. Message sebagai command

2. Message sebagai event

Message sebagai command

Message sebagai command adalah seperti ini

public class Customer

{

public void ApplyImprestAccount(new CreateNewImprestAccount());

}

CreateNewImprestAccount - ialah command, jika dibaca memang nampak akan maksud message tersebut.

Message sebagai event

Message sebagai event pula ialah kiata hendak memberitahu sesuatu dah berlaku dan apa sequence seterusnya.

public void UpdateRegistrationStatus(RegistrationStatus registrationStatus)

{

this.RegistrationStatus = registrationStatus;

if(RegistrationStatus == RegistrationStatus.InActive)

{

DomainEvents.Raise(new MailInitiatorBecameInActive

{

LicenseCustomer = this.Customer,

MailInitiator = this

});

}

}

Hendakkan kepastian baca tentang CQS.Aku pun masih baru

Naming Code yang mudah dibaca dan maintain

Macam mana nak buat naming method yang mudah dibaca dan apabila melihat naming tersebut terus boleh faham apa sebenarnya kerja yang akan dibuat oleh code tersebut. Kebaikan pada naming method yang difahami jelas maksud memudahkan untuk baca dan juga maintain.Code tersebut juag tidak perlu banyak comment.Selain dari itu jika berbincang dengan team developer yang lain naming menggambarkan situasi sebenar real world. Naming yang bagus ialah yang follow Ubiquitous Language semasa dicussion dengan subject matter expert didalam process design domain model.

Contoh -

1. Customer can request license with existing license as a parent license.
2. Customer can request license as a new license

Dulu code yang aku tulis ada seperti ini dibawah ini.

public void RequestLicense(int number,string location,Guid parentLicenseId)
{
...
}

public void RequestLicense(int number,string location)
{
...
}

Bila aku tengok balik code macam nie selepas 2 /3 bulan aku susah nak dapat tahu maksud code tersebut jika dilihat hanya pada naming method.

Aku baru sahaja bertukar cara naming code menggunakan konsep "Message". So secara basic naming code kemungkinan sama tetapi parameter akan berubah dari individual type kepada Message yang akan menggandungi parameter2 tersebut.

public void RequestLicense(CreateNewLicenseWithExistingParentLicense msg)
{
...
}

public void RequestLicense(CreateNewLicense msg)
{
...
}