𝗠𝗲𝗻𝗴𝗮𝗽𝗮𝗸𝗮𝗵 𝗠𝗼𝗱𝗲𝗹 𝗗𝗼𝗺𝗮𝗶𝗻 𝗟𝗲𝗯𝗶𝗵 𝗣𝗲𝗻𝘁𝗶𝗻𝗴 𝗱𝗮𝗹𝗮𝗺 𝗘𝗿𝗮 𝗔𝗜

Seni bina perisian sering kali menjadi perdebatan tanpa pemenang. Anda membina satu sistem. Anda tidak pernah membina alternatif di bawah keadaan yang sama. Ini menjadikan setiap keputusan sukar untuk disangkal. Apabila sesuatu sistem gagal, orang akan menyalahkan domain atau pasukan. Mereka jarang menyalahkan seni bina kerana tiada kumpulan kawalan untuk dibandingkan.

Kita memerlukan cara untuk menguji reka bentuk kita. Kita mesti memisahkan kerumitan penting (essential complexity) daripada kerumitan tidak sengaja (accidental complexity). Kerumitan penting adalah masalah yang sebenar. Kerumitan tidak sengaja adalah kekacauan yang kita cipta melalui alatan dan proses kita.

AI menjadikan pelaksanaan hampir percuma. Ini adalah peralihan yang besar. Dahulu, kesukaran menulis kod memaksa pembangun untuk mencipta struktur yang lebih baik. Jika kod anda bersepah, ia menjadi sukar untuk diurus. Kesukaran tersebut merupakan satu gelung maklum balas.

AI menghapuskan kesukaran tersebut. Ia boleh menulis kod yang bersepah dan berstruktur lemah sepantas kod yang bersih. Kesukaran akibat model yang buruk tidak lagi dirasai oleh pembangun semasa proses pembinaan (build). Sebaliknya, kesukaran itu beralih ke fasa pengeluaran (production). Anda akan mendapat data yang rosak dan tugasan integrasi yang mustahil untuk dilaksanakan.

Model domain yang kaya (rich domain model) adalah alat untuk mencegah perkara ini. Ia menjalankan tiga tugas khusus:

  • Ia membantu anda mempelajari domain dengan memaksa anda memberi bentuk kepada konsep.
  • Ia mentakrifkan domain supaya "apa yang perlu dibina" bukan lagi satu tekaan.
  • Ia mendokumentasikan domain dalam kod yang sentiasa dikemas kini melalui pengkompil (compiler).

Untuk berfungsi, model domain mesti mematuhi tiga peraturan:

  • Kekalkan kerumitan penting secara menyeluruh. Jangan taburkan satu konsep merentasi ratusan mikroservis.
  • Berikan maklum balas. Andaian yang salah sepatutnya menyebabkan ralat pengkompil (compile error), bukannya pepijat senyap (silent bug).
  • Pastikan perubahan adalah murah. Anda sepatutnya membaiki satu konsep di satu tempat, bukannya mencarinya di sepuluh servis yang berbeza.

Jika anda membahagikan domain anda terlalu awal kepada mikroservis untuk menyelesaikan masalah "bloat", anda sering kali hanya memindahkan kekacauan tersebut. Anda menukar satu "god object" dengan kekacauan teragih yang lebih sukar untuk dijejak. Kebergantungan (dependency) yang tidak dapat anda lihat adalah kebergantungan yang akan pecah semasa fasa pengeluaran.

Matlamat model domain yang kaya bukanlah untuk menjadi betul. Matlamatnya adalah untuk menjadikan kesilapan itu jelas kelihatan semasa kos pembetulan masih rendah.

Sumber: https://dev.to/leonpennings/what-is-the-reason-for-using-a-rich-domain-model-in-the-age-of-ai-3gg

Komuniti pembelajaran pilihan: https://t.me/GyaanSetuAi