Refactoring dalam desain yang digerakkan oleh domain [ditutup]

Saya baru saja mulai mengerjakan proyek dan kami menggunakan desain berbasis domain (seperti yang didefinisikan oleh Eric Evans dalam Desain Berbasis Domain: Mengatasi Kompleksitas di Jantung Perangkat Lunak . Saya percaya bahwa proyek kami jelas merupakan kandidat untuk desain ini pola seperti Evans menggambarkannya dalam bukunya.

Saya berjuang dengan ide untuk terus-menerus refactoring.

Saya tahu refactoring adalah suatu keharusan dalam proyek apa pun dan pasti akan terjadi seiring perubahan perangkat lunak. Namun, dalam pengalaman saya, refactoring terjadi ketika kebutuhan tim pengembangan berubah, bukan sebagai pemahaman tentang perubahan domain ("refactoring ke wawasan yang lebih besar" seperti Evans menyebutnya). Saya paling peduli dengan terobosan dalam memahami model domain. Saya mengerti membuat perubahan kecil, tetapi bagaimana jika perubahan besar dalam model diperlukan?

Apa cara efektif meyakinkan diri Anda (dan orang lain) yang harus Anda refactor setelah Anda mendapatkan model domain yang lebih jelas? Lagi pula, refactoring untuk meningkatkan organisasi kode atau kinerja dapat sepenuhnya terpisah dari seberapa ekspresif dalam hal kode bahasa di mana-mana. Terkadang sepertinya tidak ada cukup waktu untuk melakukan refactor.

Untungnya, SCRUM memungkinkannya untuk melakukan refactoring. Sifat berulang dari SCRUM membuatnya mudah untuk membangun potongan kecil dan mengubahnya dan itu. Tetapi seiring waktu potongan itu akan menjadi lebih besar dan bagaimana jika Anda memiliki terobosan setelah potongan itu begitu besar sehingga akan terlalu sulit untuk berubah?

Adakah yang pernah mengerjakan proyek yang menggunakan desain berbasis domain? Jika demikian, akan bagus untuk mendapatkan wawasan tentang hal ini. Saya terutama ingin mendengar beberapa kisah sukses, karena DDD tampaknya sangat sulit untuk diperbaiki.

Terima kasih!

Saya sudah menjadi penggemar berat DDD untuk sementara waktu (dengan dan tanpa jaring pengaman kerangka uji).

Seluruh konsep dan siklus daur ulang tidak berubah karena Anda sekarang menggunakan metodologi desain baru. Jika itu akan memakan waktu yang signifikan, itu harus memiliki manfaat proporsional dengan proyek untuk mendapatkan waktu dari manajemen.

Sehubungan dengan melakukannya: dalam satu contoh, saya mengambil bagian dalam 3 bulan refactoring utama karena 'terobosan' dalam pemahaman model domain. Untuk itu diperlukan tes untuk memverifikasi perilaku saat ini, tes untuk memverifikasi perilaku yang diharapkan dan perubahan pada kode panggilan. Namun manfaatnya signifikan, dan memungkinkan bisnis untuk melakukan lebih banyak hal yang perlu dilakukan sebelumnya tetapi tidak mampu. Intinya, refactoring pada dasarnya adalah 'fitur'.

Refactoring dalam Desain Berbasis Domain adalah saya pikir didorong dari kebutuhan, bukan refactor "bagus". Segera setelah Anda mengidentifikasi Model Domain yang salah, kode / sistem tidak mewakili masalah dunia nyata.

Contohnya, kami baru-baru ini mengerjakan aplikasi kompleksitas domain yang masuk akal. Itu adalah sistem Penagihan / Kontrak, dan kami memperkenalkan jenis tarif baru. Kami menggunakan proses gesit, scrum 2 minggu tepatnya.

Awalnya kami mengidentifikasi dalam model 2 harga sepenuhnya terpisah dan tidak memiliki hubungan kecuali melalui Kontrak. Namun ketika kami menyelesaikan lebih banyak cerita, kami sampai pada kesadaran bahwa mereka sebenarnya sama, terutama ketika kami mulai membungkus tarif baru dengan yang lama hanya untuk membuatnya bekerja. Ini adalah tanda peringatan pertama.

Untuk mempersingkat cerita, kami dapat menyelesaikan 90% cerita dengan model yang salah, tetapi kami sampai pada titik di mana di setiap bagian kode kami membungkus Rate baru dengan yang lama, dan / atau membuat jika newRate lain oldRate SETIAP tempat. Kami membenturkan kepala kami ke dinding tembok. Kami setengah jalan melalui bagian proyek ini, dan tahu waktu untuk menyelesaikannya akan eksponensial atau tidak bisa dijalankan dengan model domain yang salah. Jadi kami menggigit peluru, membagi cerita menjadi delapan cerita lain dan refactorer Model Domain.

Ketika kami menyelesaikan proyek, kami tahu dari belakang itu adalah hal yang benar untuk dilakukan, dan HANYA yang harus dilakukan untuk memperbaikinya.

Apakah ini butuh waktu? Ya, tetapi jika kita tidak melakukannya, itu akan membutuhkan lebih banyak waktu. Apakah DDD dilakukan dengan benar? Yah, cukup lucu kami tidak tahu tentang DDD pada saat itu, tetapi segera setelah kami menghadiri lokakarya DDD oleh Eric Evans, dan yang bisa saya dan rekan-rekan saya lakukan hanyalah mengangguk. Saya pikir jika kita tahu DDD, kita akan mengambil refactor lebih awal sehingga menghemat lebih banyak waktu.

Jika Anda mendapatkan sesuatu yang salah dalam Model Domain, penting untuk memperbaikinya. Dalam pengalaman saya, kami sedikit ketinggalan tentang bagaimana model domain terhubung ke entitas yang berbeda ketika kami mengimplementasikannya.

Hasilnya adalah bahwa orang-orang terbiasa membuat model dengan cara yang tidak diinginkan dan dengan demikian merusak bagian lain dari model untuk mencoba "membuatnya bekerja".

Segera setelah Anda menyadari bahwa ada sesuatu yang salah dalam model domain, ubah secepat mungkin. Semakin lama waktu yang Anda butuhkan untuk mengubahnya, semakin sulit untuk berubah sehubungan dengan pengguna, siapa model mental yang sekarang diadaptasi.

Untuk beberapa bagian dari kode, refactoring terus menerus berlebihan. Untuk beberapa bagian lain dari kode (dalam DDD, yang disebut Core Domain ) adalah suatu keharusan. Memahami bahwa kode bukanlah bagaimana seharusnya menempatkan beban kognitif tambahan pada pengembang (perbedaan antara pemahaman kita tentang domain dan implementasi saat ini) yang akan membuat evolusi lebih lanjut lebih sulit dan / atau mahal.

Pertanyaannya adalah: "akankah evolusi ini diperlukan?". Di Domain Inti (area yang membuat perbedaan bisnis) jawabannya adalah "Ya!". Karena itulah ramuan dari domain bisnis yang lebih diperhatikan dan yang akan membuat perbedaan bagi para pemangku kepentingan. Itu adalah tempat di mana Anda ingin menjaga kode Anda dalam kondisi sempurna, siap untuk menerapkan persyaratan berikutnya dengan upaya minimal, karena fleksibilitas Model Domain Anda.

Namun itu akan menjadi mahal bila diterapkan ke semua kode aplikasi. Area yang tidak terlalu signifikan untuk bisnis ( Subdomain Pendukung atau Generik dalam istilah DDD) mungkin memerlukan pendekatan yang kurang canggih daripada yang disediakan untuk inti.