Package Structure : Per Layer atau Per Fitur?
Manusia memiliki sifat alami untuk mengelompokan sesuatu berdasarkan tujuan atau sifat mereka. Dalam kehidupan kita sehari — hari pun demikian, kita suka mengorganisir sesuatu agar mudah diatur dan terlihat rapi. Misalnya waktu mengatur kamar kos kita, pakaianmu di lemari pakaian, sepatu kamu di rak sepatu, hati kamu di …
Begitu juga saat kita mendevelop aplikasi, kita harus mengorganisir class — class kita agar rapi dan mudah dalam mengelolanya. Mungkin ketika kamu baru memulai mendevelop aplikasi hal seperti ini tidak terlalu penting buat kamu. Tapi seiring berkembangnya aplikasi yang kamu bangun, semakin banyak class yang harus kamu organisir. Bayangkan jika aplikasi kamu punya 100 atau 1000 atau 10n (n nya isi sendiri) class? Pusing yang ada, ujung — ujungnya tipes lagi.
Package
Dalam pemrograman java package layaknya folder dimana kita bisa mengelompokan class — class yang berkaitan dalam satu folder atau package. Package juga memungkinkan kita bisa memiliki lebih dari satu class dengan nama yang sama asalkan dalam package yang berbeda. Penjelasan official nya bisa kamu baca disini ya.
Package by layer
Cara ini mungkin banyak kita ketahui dan kita gunakan. Tradisional software arsitektur membagi aplikasi dalam 3 komponen utama yakni presentation layer, business layer dan data layer.
1. Presentation layer
Presentation layer adalah layer yang berinteraksi langsung dengan client. Layer ini mengandung class atau interface yang bertanggung jawab untuk menampilkan apa yang diinginkan oleh client.
2. Business layer
Business layer mengandung core logic atau fungsionalitas dari aplikasi. Layer ini bertugas untuk memanipulasi data yang diterima dari data layer sesuai dengan proses bisnis yang diperlukan menjadi informasi yang akan ditampilkan oleh presentation layer.
3. Data layer
Data layer berfungsi untuk mengelola data yang diterima dari database.
Nah, class — class yang kita miliki dikelompokan berdasarkan layer — layer di atas. Contohnya project kamu akan terlihat seperti ini :
Keuntungan
Package by layer adalah cara yang paling banyak digunakan, diajarkan dan diaplikasikan. Hal ini tentu memudahkan programmer yang baru masuk ke dalam project. Tanpa perlu banyak bertanya dia akan tahu controller taruh dimana, service dimana, hati kamu dimana.
Kerugian
Hal yang benar — benar saya rasakan di tim adalah ketika class yang dibuat semakin banyak, semakin sulit untuk untuk diatur. Misalnya menempatkan semua class model dalam satu package, ketika kita punya puluhan bahkan ratusan model akan menjadi hal yang cukup memusingkan.
Access modifier juga jadi masalah, dengan mengelompokan class berdasarkan layer, menjadikan access modifier class kita mau tidak mau menjadi public. Ini mengakibatkan class tersebut bisa diakses oleh class yang bukan hak nya. Menjadikan codingan kita seperti indomie rebus yang susah di maintain. Seperti CTO saya pernah bilang :
Saya kalo mau review codingan orang gampang. Tinggal saya lihat aja access modifiernya. Ada class yang bisa access class lain yang bukan bagiannya ga?
CTO saya, — kayaknya belum lama ngomongnya
Terakhir, ini nih gong nya :
Di zaman semua serba microservice sekarang ini. Mengelompokan package berdasarkan layer akan menghasilkan high coupling antar package. Akan sulit ketika kita ingin memecah sebuah service menjadi service — service yang lebih kecil.
Package by feature
Dengan cara ini, kita mengelompokan class — class kita kedalam sebuah package berdasarkan fiturnya. Contoh nya akan seperti ini:
Awalnya memang akan sedikit membingungkan dan kelihatan berantakan. Tapi lama kelamaan juga terbiasa kok.
Keuntungan
Dengan mengelompokan class berdasarkan fitur, secara kasat mata kita jadi tahu aplikasi kita punya fitur apa aja. Ketika kita harus bugfix di bagian order misalnya, kita bisa langsung menuju package yang bersangkutan tanpa perlu ngubek — ngubek package yang ga ada hubungannya.
Secara access modifier juga lebih terjaga. Secara nih ya kita bisa define class ini cuma package yang bersangkutan saja yang boleh akses. Aplikasi kita juga lebih modular karena setiap package kita sudah loose coupling. Jadi lebih mudah ketika kita ingin memecah service kita menjadi service — service yang lebih kecil.
Kerugian
Menempatkan sebuah class pada suatu package membutuhkan ketelitian dan sedikit berfikir lebih. Akan ada suatu masa dimana kamu akan galau mau taruh class ini di package mana. Kaya hati kamu… (iya iya udah)
Untuk programmer yang baru bergabung ke dalam project juga menjadi tantangan tersendiri untuk memahami struktur project yang ada. Programmer tersebut dituntut untuk memahami alur bisnis dari aplikasi tersebut untuk bisa menentukan package yang tepat. Bisa jadi keuntungan juga sih, tergantung dari sudut pandang mana kita melihatnya.
Pilihan jatuh kepada…
Pada akhirnya untuk menentukan cara packaging yang mana tergantung dengan bagaimana project yang kita bangun dan tim yang kita miliki. Untuk project kamu yang sedang membangun project bersifat monolit dan tidak terlalu banyak memiliki fitur, maka package by layer bisa kamu terapkan. Sedangkan jika kamu menerapkan konsep microservice dan aplikasi kamu memiliki banyak fitur maka kamu bisa memilih package by feature.
Di tim saya misalnya, kami memiliki masalah dengan banyaknya class service yang harus di maintain, sedangkan kami masih perlu me re-use data layer seperti model dan repository class. Akhirnya kami menerapkan keduanya. Kami masih mengelompokan data layer dalam sebuah package. Namun sisanya kami kelompokan berdasarkan fitur.
Prioritas kami adalah agar class service atau business logic lebih mudah di maintain dan paling tidak business logic menjadi loosely coupling sehingga jika dikemudian hari kami ingin pecah service menjadi lebih mudah. Untuk access modifier sendiri kami masih belum disiplin dalam menerapkannya (maafkeun kami pak CTO).
Kesimpulan
Pemilihan metode packaging mana yang sesuai sekali lagi tergantung dengan kebutuhan kita. Tidak ada yang benar maupun yang salah. TAPI keputusan untuk menerapkan yang mana harus dilakukan di awal pada saat memulai project. Karena kalau kamu ubah di tengah — tengah progress pengerjaan akan berdampak sangat besar dan memerlukan effort yang tidak sedikit. Sebaiknya didiskusikan dengan tim kamu mana yang akan diterapkan, agar tidak terjadi baku hantam di kemudian hari.
Referensi
- https://dzone.com/articles/project-package-organization#:~:text=In%20the%20horizontal%20slice%2C%20packages,can%20do%20with%20the%20application.
- https://www.geeksforgeeks.org/access-modifiers-java/
- https://aptude.com/blog/entry/understanding-software-development-with-vertical-slices-vs-horizontal-slices/
- https://docs.oracle.com/javase/tutorial/java/concepts/package.html
