Begini rupa Application Service aku dalam latest project

Selepas baca tentang CQRS (Command Query Responsibility Segregation) pertengahan tahun lalu, aku mula berminat tentang apa sebenarnya CQRS. DDD developers banyak berbincang berkaitan CQRS hinggakan core pattern macam repository,services sudah berkurangan diperbincangankan.

Kalau dahulu ApplicationService aku rupanya macam nie:

void MakeDocketApproved(DocketId)

Docket GetDocket(DocketId)

DocketDto GetDocketWithCode(Code)

DocketDto GetApprovedDockets()

void ChangeDocketLocation(DocketId, NewLocation)

void CreateDocket(Docket)

void EditDocketDetails(DocketDetails)

Tetapi sekarang apabila aku guna CQRS ApplicationService aku sekarang dipecahkan kepada 2 jenis service satu Command (write) dan satu lagi Query (read). CQRS secara umum adalah Architecture decision implementation, bagaimana kita mendesignkan infrastructure. DDD masih lagi penting dari segi kepentingan domain model sebagai tempat masalah di prosess. Jadi sesuatu software project boleh sahaja hanya menggunakan DDD tanpa CQRS dan CQRS juga boleh digunakan tanpa DDD.

Apabila aku apply CQRS pada ApplicationService maka jadi seperti ini:

DocketCommandService

void MakeDocketApproved(DocketApprovedCmd)

void ChangeDocketLocation(NewDocketLocationCmd)

void CreateDocket(NewDocketCmd)

void EditDocketDetails(DocketDetailsCmd)

DocketQueryService

Docket GetDocket(CustomerId)

DocketDto GetDocketWithCode(Code)

DocketDto GetApprovedDockets()

Jadi secara umum ini adalah CQRS dimana Command dan Query responsibility diasingkan dan kelebihan service command boleh diimplement dengan cara lain dan query service boleh diimplement dengan cara yang lebih simple. Command mungkin akan melalui kesemua layer yang biasa di buat seperti controller->app service-> domain -> dataaccess->DB. Dan sebolehnya biar controller,app service seminimun kerja yang dilakukan dan kerja tersebut perlulah fokus kepada apa yang perlu sahaja dilakukan. Domain perlu didesign semaximum yang boleh untuk cover business logic (Rich Domain) dan elakkan Anemic Domain. Konsep 80% - 20% boleh diguna pakai disini, 80% responsibility perlulah berada di domain manakala lagi 20% di kongsi di layer-layer yang lain.

Manakala apabila query boleh sahaja dari controller->query service -> DB, keep it simple.