Design application - letakkan behaviour mencorakkan design anda dan bukan data

Kena ingat bila design yang penting bagaimana design tersebut menampung keperluan behaviour object2 tersebut dan jgn terlalu ambil berat bagaimana data itu di tunjukkan

Cuba kurangkan penggunaan Inheritance - Inheritance also anti pattern

Next target ialah untuk cuba design menggunakan composition/association dan elakkan terlebih guna Inheritence.

Setter dan Getter anti pattern

Sekarang aku dapat merasakan kenapa public Setter dan Getter anti pattern...

Berubah dari pemikiran CRUD ke DDD

Ada diffrent code sebegini?

var teller = s.Get(tellerId);

teller.TotalCashInHand = TotalCashInHand - amountToTransfer

dan lagi satu

var teller = s.Get(tellerId)

teller.DeductCashAmountWhenAmountTransfer(amountToTransfer);

Code atas tu kita panggil car CRUD dan yang dibawah di panggil cara DDD;

Menggunakan AggregateRoot collection untuk add entity/value object

Persoalan yang timbul bagaimana penggunaan sebenar child collections dalam AggregateRoot (AR). Pemahaman aku sebelum ini terlalu ekstrim dimana child collection itu mesti digunakan sama ada untuk add dan juga fetch child item (lazy load). Pengalaman mengajar untuk lebih flexible dalam menentukan penggunaan child collections dalam AR.

Aku bawa satu contoh, didalam library/Book Store system ada satu features yang kita panggil "Lend Book". Bagaimana kita hendak model kan ini.

BookStore 1--0..* AvailableBooks

Didalam sebuah book store akan ada 0 atau lebih Books. Jika kita nak menambah collection buku didalam book store kita akan buat begini:

var bookStore = s.get(bookStoreId);

bookStore.AddNewBook(new Book{ .. });

So bagaimana pula jika kita hendak lend book dari book store?. Oleh kerana book ialah entity dibawah AR book store maka segala aktiviti berkaitan buku sama ada command dan query pelulah melalui AR BookStore (It rules AR) . Jika dahulu aku akan buat begini:

var bookStore = s.Get(bookStoreId);

bookStore.Lend(bookId,customer);

Code didalam BookStore

public void Lend(Guid bookId,Customer customer)

{

var book = AvailableBooks.Where(c=>c.Id == bookId).SingleOrDefault();

BookLendToCustomers.Add(new BookLend{ Book = book, Customer = customer});

}

Ok code ini tiada masalah, malahan follow apa yang disuggest oleh DDD team, tetapi aku akan menghadapi performance problem jika dalam book store tersebut mempunyai 100000 buah buku. AvailableBooks collection akan load semua buku kedalam memori dan akan buat memory query untuk dapatkan buku tersebut berdasarkan bookId (bahasa bercampur-campur book/buku).

Jadi cara aku skrg lebih flexible sama ada membenarkan query ke book entity atau inject domain event kedalam Book store.

Option 1

var bookStore = s.Get(bookStoreId);

var book = s.Get(bookId);

bookStore.Lend(book,customer);

Option 2

var bookStore = s.Get(bookStoreId);

bookStore.Lend(bookId,customer);

Code didalam book store

public void Lend(Guid bookId,Customer customer)
{
var event = new BookQueryEvent{ BookId = bookId}
DomainEvent.Raise(event);

var book = event.Book;
BookLendToCustomers.Add(new BookLend{ Book = book, Customer = customer});
}

Code domain event akan diinject menggunakan any IoC library seperti castle,autofac,structuremap etc

Saper sudi share..pendapat

Real command scope dalam CQS

Minggu lepas aku submit code aku untuk group DDD buat review dan comment, dan Alhamdulillah ada banyak comment yang menarik yang dapat memperbetulkan kefahaman aku tentang CQS. Salah satu point yang aku dapat ialah apabila prosess command digunakan , hanya methodGet( jika guna Nhibernate) sahaja yang diperlukan, tiada method query akan digunakan.

Visual NHibernate & NHibernate Mold

"Sculpture is a .NET open source Model-Driven Development code generation framework ideal for creating and managing .NET Enterprise Applications."

- http://dawliasoft.com/Default.aspx

Visual designer and mapping tool for creating and editing NHibernate projects

- http://www.slyce.com/

Distributed Ajax Call

3 bulan tak update apa-apa kat sini, tersangatlah busy dan tersangat malas dan waluapun banyak yang nak share tentang pengalaman baru dalam develop distributed application tapi buntu nak start macam mana. Cuma yang aku rasa best ialah dapat selesaikan masalah Ajax call cross domain.

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.