Andrey Kopylov , direktur teknis kami, memberi tahu kami pendekatan mana yang digunakan tim pengembangan web AREALIDEA untuk merancang arsitektur aplikasi, dan apa itu Arsitektur KISS, pengembangannya sendiri, sangat bagus.
Ada banyak pendekatan untuk merancang arsitektur aplikasi. MVC, DDD, Arsitektur Bersih dan banyak lainnya.
MVC sangat cocok untuk aplikasi kecil. Ketika Anda mencoba skala, MVC berubah menjadi arsitektur paling umum di dunia TI - Big Lump of Dirt .
DDD adalah arsitektur yang hebat, tetapi tidak ada yang memahaminya. Kecuali jika pencipta sendiri dan beberapa arsitek. Tujuan dari arsitektur ini adalah untuk membuatnya dapat dipahami oleh setiap pengembang.
Clean Architecture adalah arsitektur yang hebat, tetapi implementasi penuhnya masuk akal untuk aplikasi besar. Untuk kecil dan menengah, bagi saya itu terlalu rumit.
Tren saat ini - transisi ke layanan dan layanan mikro - dengan latar belakang ini, Arsitektur Bersih menjadi terlalu berat.
Tampaknya kemudian, mari kita ambil MVC untuk layanan mikro dan berhenti pada ini. Tapi tidak, sepeda seperti itu tidak cocok untuk kita.
Komponen
Sepeda untuk proyek-proyek di agen kami dirakit dari suku cadang dari berbagai pendekatan arsitektur.
Berikut adalah komponen yang Anda butuhkan untuk membuat struktur yang mudah dimengerti dan nyaman:
- Router
- Pengontrol
- Tampilan
- Layanan
- Model
Layers
Router
Router bertanggung jawab atas permintaan routing. Ukuran router dan jumlah mereka secara tidak langsung menunjukkan ukuran aplikasi Anda. Untuk aplikasi monolitik besar, mungkin ada lebih dari satu lapisan router.
Router hadir dalam arsitektur apa pun, tetapi sering kali secara implisit. Dan karena yang jelas lebih baik daripada yang implisit, perlu menariknya keluar - untuk membuatnya menjadi bagian integral dari arsitektur.
Pengendali
Pengontrol adalah lapisan antara router dan layanan. Seharusnya tidak ada logika bisnis di controller.
Setiap pengontrol hanya mengendalikan satu entitas. Jika Anda membutuhkan lebih banyak entitas, maka Anda perlu menambahkan controller lain.
Jumlah dan ukuran pengontrol secara tidak langsung menunjukkan ukuran aplikasi Anda. Lapisan vertikal di bawah pengontrol dapat dipisahkan menjadi microservice terpisah.
Tampilan
Lihat dalam satu lapisan dengan controller, bertanggung jawab atas tampilan akhir data. Pengontrol setelah menerima data dari layanan mentransfer data ke tampilan dan mengembalikan tampilan untuk tampilan.
Dalam kasus ekstrem, View adalah JSON, XML, dan format serupa.
Layanan
Hanya Layanan yang dapat berisi logika bisnis. Suatu layanan biasanya merujuk hanya satu model. Suatu layanan dapat memanggil layanan lain.
Lapisan layanan dibagi menjadi Perintah dan Pertanyaan (perintah dan permintaan). Ini adalah pendekatan standar untuk CQRS .
Satu layanan hanya menjalankan satu fungsi. Mungkin ada sejumlah fungsi pribadi, dan hanya satu publik. Nama layanan dimulai dengan kata kerja. Contoh: GetUsers, GetPostById, UpdateUser, PublishPost. Ini adalah nama layanan yang mengisyaratkan pemisahan fungsionalitas yang benar.
Dalam kueri, kami menempatkan layanan yang tidak mengubah database. Kueri berisi satu fungsi dapatkan publik. Dalam Perintah kami menempatkan layanan yang mengubah basis data. Perintah berisi satu fungsi eksekusi publik.
Model
Model hanya berisi logika paling sederhana yang terkait dengan membaca dan menyimpan data. Selain itu, manipulasi ini mungkin tidak terkait dengan database.
Jika model berfungsi dengan database, maka satu model hanya melayani satu atau beberapa tabel.
Resep
Layanan microser
Layanan mikro, dalam pemahaman saya, harus mengelola hanya satu entitas. Oleh karena itu, arsitektur untuk layanan Microsoft yang paling sederhana akan terlihat seperti ini:
- satu router;
- satu pengontrol;
- banyak tampilan;
- beberapa Layanan;
- satu model.
Layanan
Layanan adalah aplikasi mini. Berisi:
- satu router;
- beberapa pengendali;
- banyak tampilan;
- beberapa Layanan;
- Beberapa model.
Monolith
Monolith adalah aplikasi yang bagus. Tidak ada yang mencintai monolit karena keburukan mereka. Monolith dibenarkan jika Anda mengikuti pendekatan pertama Monolith. Dalam keadaan ini, aplikasi Anda dapat tetap untuk beberapa waktu.
Monolith berisi:
- satu SuperRouter;
- beberapa router biasa;
- banyak pengendali;
- banyak Tampilan, banyak Layanan;
- banyak Model.
Itu mulai terlihat sedikit menakutkan. Di sini Anda dapat dengan jelas melihat pemisahan vertikal tambahan dari lapisan. Ini memungkinkan aplikasi untuk tetap dikelola dan dikelola. Menggergaji monolit menjadi beberapa bagian menjadi tugas mekanis murni.
Untuk menjaga harmoni arsitektur yang Anda butuhkan:
- Tambahkan satu router tingkat atas yang akan menyelesaikan jalur global - SuperRouter.
- Mendistribusikan file dalam struktur dengan modul. Artinya, sesuai dengan masa depan dipotong menjadi layanan individual.
Pengujian
Dalam kerangka arsitektur yang dipertimbangkan, hanya layanan yang akan diuji secara ketat - hanya logika bisnis yang tertanam di dalamnya. Dan Anda hanya perlu mendapatkan Model basah.
Jika Anda memiliki keinginan untuk menguji sesuatu selain layanan, maka mungkin tempat untuk logika tersebut dipilih secara tidak benar.
Kesimpulan
Menurut pendapat saya, Arsitektur KISS cocok untuk 80% proyek dan memberikan evolusi proyek yang mulus.
Pendekatan arsitektur ini akan jelas bagi semua pengembang dan untuk penerapannya dalam praktik, Anda tidak perlu membaca buku-buku tebal tentang DDD.