Domain Model Design :Siri 2

User Story : Siri 1

Aku akan cuba menjadi domain expert dan pada masa yang sama sebagai developer untuk menjayakan siri demo agile process ini. Maka segala user story yang ditulis adalah berdasarkan pemahaman aku sahaja tapi aku akan cuba sebaik mungkin menjadi domain expert.

Aku nak cuba pendekkan beberapa penerangan, so rancangan aku ialah dari user story aku akan terus buat simple domain model design. Cara aku nie short cut sedikit kerana jika mengikut process sebenar apabila mendapat senarai user story, team lead dengan developer/system analyst hendaklah berbincang dengan domain expert untuk dapatkan lebih maklumat berkaitan user story, ini adalah kerana user story hanya seperti check list antara domain expert dan developer team. Domain expert akan letakkan priority untuk setiap user story dan team akan berbincang dengan domain expert pemilihan user story yang akan dimasukkan kedalam iteration 1.

Aku rasa penerangan lebih lanjut berkaitan process tersebut aku biarkan dalam tulisan yang lain buat masa ini aku nak fokuskan kepada domain model design berdasarkan user story yang telah pun ditulis.

Sebagai User/Domain Expert/StakeHolder, aku boleh:
- Rekodkan maklumat user story, oleh itu aku boleh tahu detail user story yang aku rekodkan dan perlukan dalam project

Berdasarkan user story diatas context utama domain expert ialah merekodkan setiap user story kedalam sesuatu project. Jadi bila dianalisa terdapat 2 domain yang penting untuk merealisasikan context/tujuan tersebut iaitu:
- User
- UserStory
- Project

Untuk itu aku biasanya akan design seperti berikut:


Visual design diatas masih belum lengkap kerana relation antara domain-domain tersebut boleh dikategori sebagai kompleks.Perlu diingat relation bidirectioanal akan mengakibat relation domain mesti mengetahui antara satu sama lain. Jadi apabila design setiap relation memerlukan penelitian adakah perlu relation domain A ke domain B perlu saling kenal mengenali. Jika tidak perlu pastikan relation dalam satu hala (unidirectional). Aku akan bagi 2 solution unutk difikirkan solution mana yang lagi sesuai

Kerja baru

Esok aku akan berkerja ditempat baru sebagai Solution Architect, arghh terasa berat tanggungjawab yang aku ambil apabila terima tawaran berkerja di syarikat baru ini. Aku berharap aku boleh memenuhi tanggungjawab tersebut, dan sudah semestinya sokongan dari team members yang lain amat dihargai.

Aku juga berdoa perancangan aku untuk menjadikan team ini sebagai satu team yang mantap dalam agile process berjaya dan aku akui bukan satu kerja mudah untuk melaksanakan impian tersebut. Semoga Allah membantu aku Aminn!!

11.30 pm

User Story : Siri 1

Siri pertama aku untuk demo agile teknik gabungan beberapa tools/lib dan process dalam software development.
Aku plan hendak guna style video tapi laptop kat rumah aku nie tak de microphone, kalau aku record pun tak de suara.

Pertama aku nak perkenalkan User Story, kemudian dari user story aku akan buat simple domain model dan kemudian buat unit test yang juga simple untuk melihat keberkesanan domain model tersebut dan buat refactor kepada domain model jika ada dan juga refactor semula unit test untuk kembangkan lagi kemungkinan-kemungkinan yang difikirkan sesuai. Tapi yang penting bermula dengan kecil dan yang mudah dan jgn sesekali terover design dan juga terover test tidak bagus untuk kesihatan developer :)

Aku plan untuk buat User Story Application XPProgramming dimana applikasi ini berkeupayaan untuk merekodkan user story. User story mempunyai pelbagai variasi untuk dibuat. Aku suka style BDD user story.
Start:
Sebagai User/DomainExpert/StakeHolder, aku boleh:
- Rekodkan maklumat user story, oleh itu aku boleh tahu detail user story yang aku rekodkan dan perlukan dalam sesuatu project


Sebagai Solution Architect, aku boleh:
- Rekodkan maklumat project yang akan di bina, oleh itu aku boleh perkenalkan overview tentang sesuatu project
- Boleh pilih project dan setkan berapa kali iteration untuk project, oleh itu aku boleh setkan masa mula dan expected masa tamat sesuatu project.
- Boleh pilih user story dan letakkan tugas pembinaan kepada developer yang dipilih.
- Boleh letakkan priority pada setiap user story.
- Boleh setkan point untuk setiap user story atau point untuk project.
- Boleh setkan untuk setiap iteration ada berapa minggu didalamnya.
- Boleh setkan unutk setiap iteration user story yang akan dimasukkan.


Sebagai Developer, aku boleh:
- Lihat rekod user story yang ditulis User, oleh itu aku boleh tahu senarai user story yang telah direkod oleh user.
- Lihat rekod user story yang diletakkan pada diri sendiri.
- Lihat rekod user story yang diletakkan pada developer lain.
- Boleh letakkan estimate masa untuk setiap user story yang diberi berdasarkan point.

Sejarah

Aku sengaja letak tajuk sejarah sebab tulisan ini ada kaitan dengan sejarah tetapi bukan sejarah Malaysia atau sesiapa ,tetapi serba sedikit cerita bagaimana aku terjebak dalam gejala agile methodology.

Aku memang peminat Domain Driven Design dan Test Driven Development dan aku memang practice kedua-dua cabang ilmu ini dalam software development sekarang ini. Memang niat aku dari dulu nak kongsi bersama, tetapi halangan masa dan lain-lain mengakibat niat untuk menulis dengan lebih mendalam perlaksanaan kedua-dua methodology ini belum tercapai.
Kenapa aku pilih Domain Driven Design? Permulaan perjalanan software development aku dalam Object Oriented bermula dari teknik yang dikenali sebagai Database Driven Design, segala maklumat yang disampaikan oleh pelanggan akan di terjermahkan kedalam bentuk Database Relational Design. Tapi bila semakin lama terlibat dalam analisis design dan apabila mula terlibat dengan beberapa project yang agak besar dan sebagai mana diketahui umum requirement biasanya selalu ada perubahan walaupun disaat akhir development. Kesakitan untuk membuat penukaran design amat terasa dengan penggunaan Database Driven Design. Penggunaan strored procedure seperti menjadi kepastian dalam software development aku ketika itu. Aku pernah terlibat dengan Aplikasi Pengeluaran ubat-ubatan farmasi dimana keseluruhan table berjumlah 130 dan bayangkan apabila jika logic ditulis didalam stored procedure, jika terdapat perubahan pada mana-mana bahagian business process, selalunya aku cadangkan untuk buat change request kerana untuk menyemak semula business logic mengguna Database Driven Design adalah amat mencabar. Aku mula mencari alternative lain yang memudahkan kerja aku, pada masa tersebut aku tak dengar lagi perkataan agile apatah lagi memahami process agile yang sebenar. Tapi pada masa tersebut walaupun aku mengguna Database Driven Design aku seboleh-bolehnya cuba untuk tarik keluar semaksima logic yang boleh digunakan dia dalam code, pada ketika itu aku dah mula memahami serba sedikit design pattern walaupun tidak mahir, pernah aku cuba masukkan beberapa design pattern yang mudah,tapi hampa kerana kekurangan ilmu.
Apabila didatangi masalah dan process development menjadi perlahan, aku cuba mencari maklumat berkaitan analisis pattern . Aku mula diperkenalkan dengan teknik Peter Coad iaitu UML In Color oleh brother Hamdi, aku juga mula mendapat maklumat berkaitan Hibernate/NHibernate. Setelah beberapa bulan mencuba NHibernate aku terasa development aku semakin laju sekarang tapi masih lagi kekurangan dari segi design/architecture. Alhamdulillah sekitar tahun 2004 aku terjumpa satu artikel berkaitan Domain Driven Design menerangkan kepentingan Domain Model design dan aku agak tertarik unutk mengetahui dengan lebih mendalam. Aku mula join group Domain Driven Design dan aku mula membeli buku Domain Driven Design. Pertama kali aku baca buku tersebut aku tidak faham sangat apa yang cuba disampaikan oleh penulis buku tersebut, kerana ianya agak baru benrbanding cara yang aku gunakan. Aku juga bertanya soalan didalam group tersebut dan aku cuba memahami beberapa pattern penting didalam buku tersebut dengan buat beberapa simple test project.

Semasa melayari group DDD, ada juga beberapa artikel menerangkan tentang combination TDD+DDD dan terdetik pada ketika itu aku tertarik untuk mengetahui apa itu TDD, aku start mendapat maklumat dari group XP Programing dan aku bertambah seronok dalam software development. Combination TDD+DDD=Agile.