1st Day Pilot Project - Bukit Raja

Ada lagi beberapa jam nak close daily operation kat bukit raja, so far Alhamdulillah belum ada lagi kritikal issue dimana sytem terpaksa dihentikan. Oleh kerana sistem ini melibatkan transaksi duit so semua debit,credit, balance cukup penting. Tak senang duduk jugak le nak melayan persoalan yang timbul dari user.

Next plan aku untuk review code dan memperkemaskan semula beberapa code yang agak terbabas dari dasar.

InsyAllah ada masa aku cerita tetang scenario driven yang cuba dipraktiskan dalam development kat sini menggunakan MSpec.

Pilot Project

Selepas 5 bulan terlibat dalam development MaRS project sebagai Solution Architect (consultant), insyAllah esok pilot project untuk satu site akan digunakan. Sebulan bergelumang dengan bug fixing, code review , query tuning cukup-cukup memenatkan dan beberapa project yang lain juga sedang berjalan. Aku agak tertekan dalam situasi sekarang ini, confidence level aku untuk code Mars untuk pergi live adalah ditahap 70%, dalam kenkangan team members yang lain agak fresh dalam pengalaman membangunkan enterprise system, aku terpaksa memikul tanggungjawab sebagai consultant merangkap developer, tester. Bulan lepas 2 org dalam team nie resigned, aku tak sure sebab aku orang luar,tapi momentum project nie agak terganggu kerana salah seorang yang berhenti tersebut ialah senior developer yang juga menjadi system analyst.

Aku pada mula tekankan cara tulis code separation of concern tapi aku rasa dia orang masih tak dapt nak menjiwai kenapa perlukan cara tersebut, dan oleh kerana aku tak sempat nak review semua code orang , maka aku dapat rasakan akan ada code yang ditulis seakan TransactionScript .

Code scenario test aku masih cover hanya 40% dari keseluruhan scenario penting. Aku berdoa, semoga pilot project berjalan lancar dan nationwide deployment pun success.

Just untuk update, dari segi framework, tools dan approach yang aku guna dalam team ini.

.Net Framework 3.5
ASP.Net MVC 1
NHibernate 2.1
FluentNHibernate
NHibernateLinq
Coolite - ExtJS
MSpec, NUnit
IIS 7
SQL Server 2005

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.

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)
{
...
}

NHibernate - Training

Minggu lepas first time aku bagi training untuk company luar dan training tersebut di kelolakan oleh pihak Syarikat aku berkerja, maka aku tak perlu bercuti unutk buat consultation training. 6 orang developer datang selama 4 hari dari sebuah company. Tajuk yang aku pilih untuk train dia orang ialah Building Enterprise Application using NHiberante & Domain Driven Design.

Kebanyakkan masa dalam training menjurus kepada hands on training. Hari pertama banyak aku sentuh tentang teori/konsep ORM/NHibernate. Aku juga bawa contoh penggunaan TDD dalam development dan aku buat example tanpa prepare so nak tunjukkan serba sedikit cara real start project from scratch. So bila run TDD tu nampak lah kebaikan sebab bila buat impromptu nampak lah apa yang aku expect code tak menghasilkannya kerana ada silap dalam code base tersebut.

Nanti aku tulis lagi, dah masa bulan malas nak update...

NHibernate - using list sebagai collection

Aku jarang guna list <list> sebagai collection untuk NHibernate. Biasanya aku guna bag configuration untuk collection. Bag is ordered collection
Dalam NHibernate collection boleh di congifigure sebagai <set>, <list>, <map>, <bag>, <array>and <primitive-array>

Cuma dalam situasi tertentu aku perlukan guna <list> untuk dapatkan index. Cuma jika <list> in diconfigurekan sekali dengan inverse=true index akan null. Jadi untuk guna kena letak inverse=false

API Flexibility or Dynamic

Pada pendapat aku API code hanya dibuat berdasarkan process dan bukan berdasarkan kemampuan design tersebut, ini adalah kerana untuk mengelakkan confuse walaupun ada comment pada code atau documentation.

Untuk lebih mudah faham jika dalam scenario tu dikehendaki 2 process dilakukan kerana turutan/aturan/sequence dari UI maka buatlah code yang support 2 process tersebut jangan buat code api yang boleh buat dalam kedua-dua process tersebt kedalam hanya 1 process, jika tidak diperlukan.

Update

Lately busy dengan macam-macam benda duniawi, then since last week nak online guna Celcom broadband kat area rumah aku nie ada masalah, adalah dlm 10 min dlm HSDPA connection lepas tu terus je drop ke GPRS, jadi banyak kerja aku terganggu. Sekarang nie aku cuba pula guna PIWimax so far nie first day dan nampak macam ok, tak tahu lah pulak bila org dah start ramai subscribe.

Aku pun sekarang dah kurang buat coding kat office, walaupun kerja banyak dan aku sepatutnya membantu teams members aku yang lain, cuma aku dah start macam kura-kura bila masuk bab programming hehehe.. lagi slow dari budak fresh grade.

Aku rasa aku kekurangan fokus, bila aku nak buat programming tiba-tiba dapat call..kena check something, kena meeting, kena update something pada CIO ..etc (alasan je tu)... aku nak kena bercuti fikirkan pasal programming dan kerja, tapi waktu nie nak pergi bercuti pun time musim H1N1

Banyak juga update dalam software development dalam jangka masa sebulan nie. Nanti bila mode aku datang semula nak menulis aku akan update..insyAllah

DDD : Messaging

Konsep messaging banyak digunakan dalam DDDD atau dikenali sebagai Distributed Domain Driven Design. Dalam .Net community setahu aku ada 2 transport application iaitu NServiceBus dan MassTransit. Cuma messaging approach boleh juga digunakan dalam cara Domain Driven Design yang biasa tanpa menggunakan any messaging transport.

Aku tertarik dengan konsep messaging dari segi kekemasan code dan keupayaan code tersebut bila didesign ala messaging. Kalau mengikut DDDD, Domain akan reference/couple dengan messaging structure manakala jika follow DDD, service akan reference/couple dengan messaging structure.

Dalam post kali nie aku nak bawa contoh bagaimana hendak guna DDD dengan messaging iaitu service reference messaging structure.

Aku baru je nak mencuba, so kalau silap bagi tahu.Apa itu message? Kalau ditanya kepada aku apa itu message jawapannya ialah satu set yang mengandungi samaada arahan atau maklumat sesuatu Context. Sebagai contoh context Tunjuk jalan ke Masjid Shah Alam. Maka terdapat arahan dan maklumat yang perlu letakkan didalam message untuk di hantar kepada si penerima. Penerima boleh jadi rakan sekerja, pemandu teksi atau sesiapa yang faham message tersebut. Berdasarkan message tersebut si penerima akan response berdasarkan apa yang diminta dan supporting maklumat.

Message : Tunjuk Jalan Ke Masjid Alam

Arahan : Sila bagi arahan untuk Ke Masjid Shah Alam
Maklumat 1 : Aku sekarang di lokasi seksyen 9 dan destinasi Masjid Shah Alam
Maklumat 2 : Aku nak pergi menaiki kereta

namespace Direction.Services
{
    public interface IMessage
    {
    }

    public interface IServiceHandler<TMsg> where TMsg : IMessage
    {
        void Handle(TMsg msg);
    }


    public class TunjukJalanKeMasjidShahAlamMenggunakanKereta : IMessage
    {
        public string from { set; get; }
        public string to { set; get; }
    }

    public class TunjukJalanKeMasjidShahAlamBerjalanKaki : IMessage
    {
        public string from { set; get; }
        public string to { set; get; }
    }

    public class TunjukJalanKeMasjidShahAlamMenaikiBasikal : IMessage
    {
        public string from { set; get; }
        public string to { set; get; }
    }

    public class DirectionService :
        IServiceHandler<TunjukJalanKeMasjidShahAlamBerjalanKaki>,
        IServiceHandler<TunjukJalanKeMasjidShahAlamMenggunakanKereta>
       
    {
       
        #region IShowDirection Members

        public void Handle(TunjukJalanKeMasjidShahAlamBerjalanKaki msg)
        {
            //Send to Domain to calculate and show the possible way
            //Direction.FindFrom(msg.from).FindTo(msg.to).With(Transportation.Leg);
        }

        public void Handle(TunjukJalanKeMasjidShahAlamMenggunakanKereta msg)
        {
            //Send to Domain to calculate and show the possible way
            //Direction.FindFrom(msg.from).FindTo(msg.to).With(Transportation.Car);
        }

        #endregion

      
    }
}

Code diatas tidak di test dan hanyalah imiginasi sahaja untuk tatapan umum.

DDD : AggregateRoot rules

Salah satu pattern yang tersangat penting dalam Domain Driven Design ialah AggregateRoot. Dan ianya juga adalah pattern yang nampak mudah tapi susah untuk di pilih semasa didesign di dalam Domain Model.

Apa definisi AggregateRoot? Kalau mengikut buku Domain Driven Design dan setelah membacanya aku boleh membuat kesimpulan pemahaman aku sendiri yang pada aku betul, iaitu AggregateRoot ialah anda mengroupkan beberapa entity atau value object kepada sesuatu object entity yang akan menjadi ketua dan object entity ini akan bertindak menjaga sebarang anasir-anasir baik dan jahat dari luar yang menganggu kelompok/komuniti. Ini bermakna jika ada permintaan dari pihak luar yang bukan penduduk dalam komuniti AggregateRoot tadi maka permintaan tersebut perlulah melalui ketua tadi dan si ketua yanag akan memanggil pengikutnya (Aggregate) untuk bertindak dan tindakan yang berlaku adalah diketahui oleh siketua. Ok ini bahasa mudah yang aku nak cerita, bahasa susah korang google lah sendiri.

Kepentingan AggregateRoot jika di design dengan betul, akan mengurangkan keserabutan (complexity).

Rule yang pertama aku follow, developer lain ada rules masing-masing mengikut pemahaman dia orang. Aku pun baru je faham tu pun kekadang salah pilih AggregateRoot. Lagi satu peringatan jika kesilapan memilih AggregateRoot boleh menjadikan design anda menjadi lebih komplex dan aku pernah merasa keperitan ini. Aku akan hanya pilih AggregateRoot bila perlu dan jika tidak perlu aku tak nak buat. Ianya bukan kemestian, cuma memastikan kekuatan design. Sebelum ini 2/3 bulan sebelum ini pemilihan aggregate root macam kemestian tapi apabila dah terjerat baru kutahu langit itu tinggi. Walaupun dari segi turutan dalam design domain model priority AggregateRoot ialah ketiga penting setelah mengenal pasti entity/value object (1) dan relation association antara object(2). Ianya berada ketangga ketiga hitz sepanjang zaman volume 1 kompilasi, tapi kekuatan design banyak berkait rapat dengan AggregateRoot.

Rule aku yang kedua, Aggregate ialah rakyat marhaen dibawah jajahan takluk AggregateRoot. Jika delete AggregateRoot, maka semua Aggregate akan turut sama terkorban dan mengorbankan diri (kes ikut ketua tanpa usul periksa U jump, I jump) mereka ini tidak nak menjadi anak yatim piatu. Dalam erti kata sebenar Aggregate ini tidak bernilai jika tidak bersama-sama AggregateRoot dan mesti ingat nilai ini adalah berdasarkan Context. Contoh nilai berdasarkan context ialah jika anda masuk kekedai Kereta sama ada baru atau terpakai (second hand) , tujuan anda ialah hendak membeli Kereta itu ialah Context, maka bayangan anda ialah sebiji kereta yang normal yang lengkap dengan body, engine, interial dan tayar. Apa perasaan anda jika hendak beli kereta tapi oleh kerana bodynya tidak dijual dan yang dijual hanyalah tayar apakah nilai tayar dalam context awal tadi. Salesman tu mungkin kena baling dengan tayar tu kot. Tapi sebaliknya jika anda dah ada sebuah kereta tapi tayar anda bocor dan perlu diganti, maka jika anda pergi ke kedai service kereta, mekanik tu akan ganti tayar anda bukan ganti kereta anda, disini tayar adalah lebih bernilai mengikut context tayar bocor.

Rule yang ketiga, sebarang kerja yang dilakukan oleh aggregate , maka AggregateRoot perlu memantau agar perkara-perkara tidak senonoh tidak berlaku dalam jagaan dia. Ok ambil contoh Mursyidul Am PAS ialah AggregateRoot bagi Aggregate jemaah PAS, maka sebarang aktivi seperti Unity Goverment ke atau apa, beliau kena tahu dan tegur jika ada pelanggaran berlaku yang merugikan Islam dan Parti, Aggregate tidak boleh buat sesuka hati nak berdua-duaan dengan orang lain. Orang lain dari luar parti perlu berbincang dengan Mursyidul Am PAS kenapa perlu berdua-duaan untuk kebaikan ummah ke atau apa ke. So jika bukti keikhlasan maka Mursyidul Am PAS mugkin ada letak syarat jika anda ingin kawan dengan si Aggregate A dari Terengganu maka syaratnya Islam mestilah didahulukan dan lain-lain syaratnya. Pendekkan cerita katakan lah Mursyidul Am PAS setuju dan berkawanlah si orang luar tadi dengan Aggregate A, dia pun suruh lah bermacam-macam, suruh buat ini dan buat itu dan semasa perkerjaan tersebut dibuat semua informasi tersebut dipantau terus oleh Mursyidul Am PAS dan tiba-tiba dilihatnya orang luar itu suruh Aggregate A menari ronggeng, wah nie dah kes berat , berdasarkan syarat yang dipersetujui maka terdapat pelanggaran syarat maka perkerjaan Aggergate tadi akan dihentikan dan timbul Pop Up Message "Tak Takut Allah ke hehehehe ". Maka tugas AggregateRoot tadi menjaga supaya tidak tercemar Agregate-Agregate yang berada dibawahnya.

Kesimpulan 3 rules yang aku rasa paling hitz yang boleh dijadikan panduan memilih bakal AggregateRoot, walaupun ada rules lain tapi tidak sepenting rules2 ini. Cerita yang dibawa tiada kena mengena dengan yang hidup atau yang mati dan tiada kena mengena dengan isu sekarang.

Selamat beraggregate root - jangan nak rongeng2