Daripada seni bina berlapis kepada DDD. Pengalaman saya tentang penghijrahan dan pemotongan monolit

Hari ini kita akan bercakap tentang seni bina aplikasi bahagian belakang dan membandingkan dua cara popular penstrukturan projek: bawang dan DDD. Saya akan memberitahu anda tentang kelebihan pendekatan kedua berbanding pengalaman pertama dan terkini saya memindahkan projek kepada seni bina heksagon. Teks ini adalah untuk mereka yang telah bekerja dengan seni bina berlapis dan mahukan lebih banyak lagi (contohnya, mula bekerja dengan perkhidmatan mikro).

Mari kita mulakan dengan seni bina berlapis. Berlapis, juga dikenali sebagai seni bina bawang, ialah seni bina di mana kami membahagikan keseluruhan aplikasi ke dalam lapisan. Setiap lapisan mempunyai fungsinya sendiri, tujuannya yang jelas. Sebagai contoh, interaksi dengan pangkalan data: lapisan sedemikian harus mengandungi fungsi eksklusif untuk berinteraksi dengan pangkalan data, dan tidak ada yang lain. Seharusnya tiada interaksi dengan pelanggan atau mana-mana fungsi lain.

Selalunya dalam seni bina berlapis terdapat 3 lapisan utama pada bahagian belakang: untuk interaksi dengan storan, logik aplikasi dan lapisan perwakilan.

Berikut adalah seni bina tiga lapisan biasa, segala-galanya mengenainya agak mudah. Permintaan dihantar melalui semua lapisan, memperoleh borang akhir (permintaan dalam storan), respons membuat perjalanan pulang, bertukar menjadi beberapa format yang mudah untuk klien (JSON, XML, dll.).

Saya telah menggunakan seni bina ini untuk masa yang agak lama dalam semua projek saya dan dalam permulaan yang saya sertai. Dalam projek haiwan peliharaan kecil, pendekatan ini benar-benar berkesan dan tidak menyebabkan masalah, tetapi dalam projek yang lebih besar, huru-hara bermula.

Salah satu prinsip utama seni bina berlapis ialah keupayaan untuk menggantikan mana-mana lapisan dengan yang serupa supaya tiada lapisan lain yang perlu diubah sama sekali. Tetapi pada hakikatnya, semakin banyak entiti muncul dalam projek, semakin sukar untuk mematuhinya.

Pada mulanya, terlalu banyak kebergantungan muncul, dan menjadi semakin sukar untuk mengawalnya. Ini membayangkan pengabaian monolit (selepas semua, bawang adalah seni bina monolitik). Beban tidak diagihkan dengan betul dan aplikasi mengalami lebihan beban. Selanjutnya, lapisan mula bercampur - ia menjadi semakin sukar untuk mengasingkan logik aplikasi. Ia menjadi semakin sukar untuk mengembangkan aplikasi, kebergantungan membuat penyahpepijatan menjadi neraka, dan pembangunan menjadi sangat perlahan. Menambah bahan api pada api adalah corak seni bina yang ketat yang mengehadkan keupayaan pemaju. Jika anda membaca teks ini, anda mungkin pernah mengalaminya. Keadaan yang sama berlaku dalam projek kami.

Jelas sekali, dalam keadaan sedemikian adalah perlu untuk memotong monolit, beralih kepada seni bina lain dan memperkenalkan corak yang lebih bebas. Kami memilih DDD, ia kelihatan seperti penyelesaian yang jelas. DDD (Reka Bentuk Didorong Domain, seni bina heksagon) ialah seni bina mikro (walaupun boleh digunakan sebagai monolitik) yang dibina atas abstraksi. Jika anda hanya mempunyai pengalaman bekerja dengan seni bina berlapis, maka sebagai contoh kasar anda boleh membayangkan seni bina tiga lapisan yang sama, di mana bukannya lapisan interaksi dengan penyimpanan terdapat lapisan interaksi dengan semua teknologi secara umum, dan terdapat juga lapisan berasingan dengan abstraksi. Abstraksi secara amnya adalah perkara utama dalam DDD. Abstraksi ini, serta alat bantu dan entiti tunjuk cara (templat, gambar rajah) diasingkan daripada aplikasi, dan akibatnya seni bina kelihatan seperti ini:

Kelebihan utama seni bina heskagon berbanding seni bina berlapis ialah kebolehkembangan. Lebih mudah untuk melaksanakan ciri baharu, parameter baharu dan fungsi baharu kerana terdapat lebih sedikit kebergantungan.

Pada mulanya, struktur ini kelihatan tidak logik kepada saya, tetapi dalam proses beralih kepada DDD, saya mendapati bahawa ia menjadi lebih mudah untuk menulis, kerana infrastruktur telah dikeluarkan sepenuhnya walaupun dari lapisan paling bawah aplikasi, dan di sana adalah lebih sedikit kebergantungan. Malah terdapat beberapa jenis kelegaan yang tidak rasional dan kebebasan bertindak secara tiba-tiba ke atas setiap entiti. Pendekatan ini sekarang nampaknya lebih logik bagi saya daripada seni bina berlapis.

Tetapi anda perlu ingat bahawa seni bina sedemikian tidak masuk akal jika terdapat 2-3 entiti dalam projek, kerana DDD digunakan terutamanya sebagai seni bina mikroperkhidmatan dalam aplikasi dengan sejumlah besar kebergantungan, yang tidak boleh berada dalam projek haiwan peliharaan kecil dengan 2-3 entiti. Di sesetengah tempat, seni bina linear yang ringkas pun sudah memadai. Dan secara umum, menggunakan teknologi dan amalan yang berbeza begitu sahaja, secara tidak perlu, adalah amalan yang tidak baik, melainkan anda memutuskan untuk mencuba untuk belajar.

P.S. Dan anda perlu terpikat dengan TGC: https://t.me/dmkjfss

Atas ialah kandungan terperinci Daripada seni bina berlapis kepada DDD. Pengalaman saya tentang penghijrahan dan pemotongan monolit. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!