Satu lagi Cara untuk Menstruktur Projek Symfony anda

Seni bina Perkhidmatan MVC adalah sangat biasa dalam projek Symfony yang dirasakan seperti satu-satunya cara. Ia mudah, biasa dan berfungsi... sehingga tidak. Apabila projek anda berkembang, keretakan mula ditunjukkan: logik perniagaan anda ada di mana-mana, gelagat apl tidak jelas dan mengekalkan kod menjadi menyakitkan. Walaupun ia adalah pendekatan yang paling biasa, Symfony tidak memaksa anda untuk terus menggunakannya.

Bagaimana jika ada cara yang lebih baik ?

---

Kekecewaan Menggunakan Seni Bina Perkhidmatan MVC

 

Logik Domain Tersebar Di Mana-mana

Apabila projek berkembang, logik perniagaan cenderung merebak ke seluruh pangkalan kod. Setiap lapisan projek — pengawal, perkhidmatan, borang, entiti — akhirnya mengandungi bit dan kepingan model domain. Ini menjadikannya semakin sukar untuk fokus pada mana-mana bahagian tertentu.

 

Sempadan Projek Tidak Jelas

Apabila seni bina anda disusun mengikut lapisan teknikal, ia menjadi lebih sukar untuk mengenal pasti sempadan yang jelas antara konteks yang berbeza apabila projek berkembang. Kekurangan kejelasan ini boleh menyebabkan kod dan cabaran penyelenggaraan yang diganding rapat.

 

Gelagat Projek Tidak Jelas

Memandangkan seni bina lalai menekankan lapisan teknikal, ia menjadi agak mencabar untuk memahami gelagat projek. Anda mungkin membuat kesimpulan bahawa entiti tertentu diuruskan oleh perkhidmatan tertentu atau meneka skema pangkalan data, tetapi gelagat sebenar projek, yang merupakan aspek yang paling penting, masih tidak jelas dan tersirat.

 

Kitaran Hayat Berbeza

Apabila logik perniagaan tersebar di seluruh projek dan dicampur dengan butiran pelaksanaan, ia menjadi sukar untuk mengembangkannya secara bebas. Dari masa ke masa, Kitaran hayat logik perniagaan cenderung menjadi lebih lama daripada butiran pelaksanaan (seperti rangka kerja, API pihak ketiga atau pangkalan data). Ketidakpadanan ini memaksa anda untuk menulis semula sebahagian besar kod apabila perubahan kecil berlaku dalam kebergantungan.

---

Cara Lebih Baik untuk Menstrukturkan Seni Bina Anda

 

Asingkan Logik Perniagaan

Untuk memudahkan memfokuskan pada logik perniagaan apabila diperlukan, langkah pertama ialah mengasingkannya daripada keseluruhan projek. Untuk mencapai ini, cipta folder Domain. Folder ini menjadi teras projek, di mana logik perniagaan dimodelkan menggunakan objek PHP tulen, bebas daripada pergantungan pada butiran pelaksanaan. Walaupun selebihnya projek bergantung pada folder ini, folder Domain tidak bergantung kepada sesiapa.

Di dalam folder Domain, fail hendaklah dikumpulkan mengikut tujuan domain dan bukannya tujuan teknikal. Ini bermakna tiada folder Entiti, Perkhidmatan atau Pengawal di sini, hanya nama folder yang sepadan dengan ciri atau konsep domain.

 

Pintu Depan Domain

Aspek yang paling penting dalam projek ialah apa yang lakukan, tindakan yang boleh dikendalikannya. Tindakan ini mewakili gelagat projek dan harus berfungsi sebagai satu-satunya cara untuk mengakses logik perniagaan. Untuk mencerminkan perkara ini, buat folder Application yang secara eksplisit mempamerkan semua gelagat projek. Sebagai contoh, sebagai pembangun baharu pada projek itu, saya sepatutnya dapat memahami sepintas lalu perkara yang mampu dilakukan oleh projek dengan melihat folder ini.

 

Menyambung ke Dunia Luar

Dengan folder Apl dan Domain, ia menjadi mudah untuk memfokuskan pada logik perniagaan. Walau bagaimanapun, pada satu ketika, logik perniagaan ini perlu berinteraksi dengan sistem luaran. Untuk mengendalikan perkara ini, buat folder ketiga yang dipanggil Infrastruktur, yang mengandungi semua butiran pelaksanaan seperti kod khusus rangka kerja, sambungan pangkalan data dan perpustakaan.

Fail dalam folder Infrastruktur bergantung pada fail Apl dan Domain. Contohnya, mereka mungkin memanggil pengendali aplikasi daripada folder Apl atau melaksanakan antara muka yang ditakrifkan dalam folder Domain.

Secara konkrit, dalam Symfony, ini melibatkan pengubahsuaian folder Pengawal dan mengisytiharkan perkhidmatan yang melaksanakan antara muka yang mana.

# config/routes.yaml

controllers:
    resource:
        path: ../src/Catalog/Infrastructure/Controller/
        namespace: App\Catalog\Infrastructure\Controller
    type: attribute

 

Dedahkan Sempadan

Apabila projek anda berkembang, anda mungkin dapati bahawa sesetengah bahagian logik perniagaan memerlukan ruang mereka sendiri dalam seni bina. Penunjuk yang baik ialah apabila istilah yang sama mula mempunyai makna yang berbeza bergantung pada konteks. Sebagai contoh, perkataan Produk mungkin merujuk kepada produk kilang, produk gudang atau produk e-dagang, masing-masing memerlukan modelnya sendiri. Objek tuhan juga boleh menjadi penunjuk yang baik; kelas Pengguna selalunya mempunyai jenis isu ini dalam projek Symfony.

Apabila ini berlaku, tiba masanya untuk mengekstraknya dan membiarkan logik perniagaannya berkembang secara bebas.

Sesetengah konteks akan membentuk teras projek anda, manakala yang lain akan menyokongnya. Konteks generik, seperti Auth, boleh menggunakan seni bina yang lebih ringkas kerana ia bukan pusat domain anda

Dalam gambar ini, kita dapat melihat bahawa konteks Auth menggunakan struktur Symfony standard, konteks Pesanan dan Katalog menggunakan seni bina tertumpu domain dan konteks Penghantaran menggunakan seni bina tertumpu ciri.

 

Modulariti Bertambah

Jika konteks tertentu berkembang ke tahap yang perlu diskalakan secara bebas, pertimbangkan untuk membahagikannya kepada unit penggunaan yang berasingan.

Walau bagaimanapun, jangan tergesa-gesa dalam langkah ini. Mulakan dengan menjadikan projek anda modular, dan jika anda perasan bahawa konteks perlu berskala secara individu, kemudian gunakannya secara berasingan.
Hanya bahagikan pangkalan kod jika timbul cabaran organisasi, seperti dua pasukan bergelut untuk bekerjasama dalam pangkalan kod yang sama.

Pergi Lebih Jauh

• Simon Brown - Monolith Modular

---

Konsep

Semasa kami meneroka penyelesaian ini, kami menggunakan beberapa konsep ketukangan. Mari namakan dan terangkan secara ringkas, supaya anda boleh menyelami setiap satu dengan lebih mendalam.

 

Bahasa Ubiquitous

Di sebalik istilah luar biasa ini terdapat konsep yang sangat mudah. Bahasa di mana-mana ialah perbendaharaan kata yang digunakan oleh pasukan anda untuk menerangkan model domain anda. Perbendaharaan kata ini harus didokumentasikan dan digunakan secara konsisten di mana-mana, dalam perbualan produk, pangkalan kod dan seterusnya.

Secara konkrit, buat fail penurunan nilai pada akar Konteks Terhad dan kumpulkan orang produk, pakar domain dan pasukan teknologi untuk mentakrifkan setiap konsep projek anda.

Pergi Lebih Jauh

• Eric Evans - DDD - Bab 2 : Komunikasi dan penggunaan bahasa
• Martin Fowler - Bahasa Ubiquitous

 

Konteks Terbatas

Konteks bersempadan mentakrifkan sempadan linguistik dalam projek anda, memisahkan bahagian sistem di mana bahasa di mana-mana tidak sejajar lagi. Alatan seperti Peta Konteks dan Penyerbuan Acara boleh membantu mengenal pasti sempadan ini.

Konteks terikat ialah konsep abstrak; ia boleh dilaksanakan dalam pelbagai cara, daripada folder ringkas dalam monolit modular kepada gugusan dalam seni bina perkhidmatan mikro.

Pergi Lebih Jauh

• Eric Evans - DDD - Bahagian IV : Reka Bentuk Strategik
• Vaughn Vernon - IDDD - Bab 2 : Domain, Subdomain dan Konteks Sempadan
• Martin Fowler - Konteks Terbatas

 

Pelabuhan dan Penyesuai, Heksagon, Bawang, dan Seni Bina Bersih

Semua seni bina ini bertujuan untuk mengasingkan logik perniagaan daripada butiran pelaksanaan. Sama ada anda menggunakan Pelabuhan dan Penyesuai, Heksagon atau Seni Bina Bersih, idea terasnya ialah menjadikan rangka kerja logik perniagaan-agnostik dan mudah untuk diuji.

Sebaik sahaja anda memikirkan perkara ini, terdapat spektrum penuh pelaksanaan dan yang terbaik bergantung pada konteks dan pilihan anda. Kelebihan utama seni bina ini ialah, dengan mengasingkan logik perniagaan anda, ia membolehkan ujian yang lebih cekap.

Pergi Lebih Jauh

• Alistair Cockburn - Seni Bina Heksagon
• Uncle Bob - Seni Bina Bersih
• Herberto Graca - DDD, Heksagon, Bawang, Bersih, CQRS, … Bagaimana Saya Menggabungkan Semuanya

 

Seni Bina Menjerit

Idea untuk menyusun folder dan fail untuk "menjerit" logik perniagaan dikenali sebagai Screaming Architecture. Konsep ini menekankan bahawa struktur kod anda harus menjelaskan tujuan projek dengan segera. Matlamatnya adalah untuk pembangun baharu memahami perkara yang projek itu lakukan sepintas lalu.

Saya amat mengesyorkan membaca artikel Uncle Bob mengenai topik itu—perbandingannya dengan pelan rumah amat bernas.

Pergi Lebih Jauh

• Uncle Bob - Seni Bina Menjerit

 

Seni Bina Menghiris Menegak

Penghirisan menegak menyusun projek anda mengikut ciri, membolehkan setiap ciri berkembang secara bebas. Ia membolehkan anda menggunakan seni bina yang berbeza pada ciri yang berbeza berdasarkan kerumitan dan kematangan.

Walaupun idea itu menarik, ia memerlukan jurutera berkemahiran tinggi untuk melaksanakan dan mengekalkan seni bina sedemikian dengan berkesan.

Pergi Lebih Jauh

• Jimmy Bogard - Seni Bina Slice Menegak
• CodeOpinion - Seni Bina Slice Menegak, bukan Lapisan!

---

Fikiran Akhir

Cara anda menstruktur projek Symfony anda mempunyai kesan yang mendalam pada kebolehskalaan, kebolehselenggaraan dan kejelasannya. Dengan mengasingkan logik perniagaan anda dan membuat tingkah laku yang jelas, anda akan mencipta sistem yang lebih mudah difahami dan berkembang.

Jika anda baru dengan idea ini, jangan risau, ketukangan perisian ialah satu perjalanan, bukan destinasi. Konsep ini mungkin kelihatan hebat pada mulanya, tetapi setiap satu akan membantu anda memberikan lebih nilai kepada perniagaan anda.

Ada soalan atau ingin berkongsi pengalaman anda? Letakkan mereka dalam komen! Dan nantikan artikel seterusnya ?

Atas ialah kandungan terperinci Satu lagi Cara untuk Menstruktur Projek Symfony anda. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!