Menggunakan paket (permata, telur, dll.) Untuk membuat arsitektur terpisah

Masalah utamanya

Melihat dukungan yang baik sebagian besar platform pemrograman modern memiliki untuk manajemen paket (berpikir gem, npm, pip, dll), tidak masuk akal untuk merancang aplikasi atau sistem terdiri dari paket yang dikembangkan secara internal, sehingga untuk mempromosikan dan menciptakan arsitektur longgar digabungkan?

Contoh

Contohnya adalah membuat paket untuk akses basis data, serta untuk otentikasi dan komponen lain dari sistem. Ini, tentu saja, menggunakan paket eksternal juga. Kemudian, sistem Anda mengimpor dan menggunakan paket-paket ini - alih-alih memasukkan kodenya ke dalam basis kodenya sendiri.

Pertimbangan

Bagi saya, tampaknya ini akan mempromosikan decoupling kode dan membantu pemeliharaan, hampir dalam jenis aplikasi berbasis Web vs desktop (pembaruan diterapkan hampir secara otomatis, basis kode tunggal untuk fungsi tunggal, dll.).

Apakah ini tampak seperti konsep desain yang rasional dan waras? Apakah ini benar-benar digunakan sebagai cara standar penataan aplikasi saat ini?

Saya sudah terlibat dalam proyek seperti ini sekarang dua kali (keduanya menggunakan nuget dengan .NET), dan saya akan mengatakan bahwa secara seimbang itu adalah ide yang bagus. Tetapi jarak tempuh Anda mungkin berbeda.

Jangan berpikir sejenak bahwa itu adalah obat mujarab, bahwa itu akan menyelesaikan semua masalah Anda tanpa menyebabkan yang baru. Manajemen rilis akan mendapatkan lapisan kompleksitas yang sama sekali baru, Anda harus berurusan dengan masalah ketergantungan versi yang tidak pernah Anda ketahui, dan Anda akan memiliki waktu ketika Anda mengutuk keputusan karena Anda harus memutakhirkan empat paket berbeda karena suatu bug kecil yang perlu Anda perbaiki dan lepaskan dengan cepat.

Di sisi lain, Anda benar bahwa itu memisahkan hal-hal dengan baik. Kecuali jika Anda berlebihan, Anda mungkin akan menemukan lebih banyak kesempatan ketika Anda berpikir "oh, itu bekerja dengan baik," daripada "itu menambah banyak usaha." Jika Anda memiliki kode yang dibagikan di antara banyak aplikasi, ini sangat efektif karena Anda dapat dengan mudah meningkatkan aplikasi secara mandiri.

Dan, jika Anda seperti saya, Anda akan dengan cepat mulai menulis aplikasi uji yang menggunakan paket Anda, untuk menghapus seluruh lapisan aplikasi dari proses pencarian bug Anda. Dan itu, dalam dirinya sendiri, bisa lebih dari sepadan dengan biaya.

Ini adalah ide yang bagus, semuanya. Anda perlu berpikir tentang menyiapkan repositori paket internal (biasanya disebut "repositori artefak" di dunia Java, atau "server pypi" di dunia Python), sehingga Anda tetap menyimpan paket-paket yang tidak Anda inginkan atau tidak bisa ' t rilis sebagai sumber terbuka.

Seperti @pdr telah dicatat, bersiaplah untuk memiliki ketergantungan Anda sendiri , di mana perubahan ke beberapa paket terlebih dahulu memerlukan perubahan lain dalam paket lain, dan ini berarti tidak hanya mengubah satu baris kode, tetapi mengujinya, mungkin menerima perubahan itu, membuat rilis, dan mengunggah rilis ke repositori paket yang disebutkan di atas. Dan kemudian mengubah apa yang ingin Anda ubah.

Satu-satunya resep yang bisa saya berikan dari pengalaman saya untuk mencoba dan meminimalkan ini: jangan hanya mengandalkan abstrak konsep umum dari paket Anda menjadi paket "umum" atau "kerangka" . Ini bisa tampak seperti hal yang sangat obyektif untuk dilakukan, tetapi itu akan mengarah pada paket monster yang perlu sering, kemungkinan perubahan dan rilis yang kontradiktif. Jauh lebih baik, pikirkan fungsionalitas dalam sistem Anda, dan buat paket pembantu untuk masing-masingnya, seperti yang telah Anda uraikan dalam pertanyaan Anda.

Selain itu, manfaat utama yang akan Anda dapatkan adalah aplikasi Anda terisolasi dari banyak dependensi, sehingga Anda dapat menukarnya tanpa rasa sakit.