Saya menggunakan panduan gaya AngularJS. Di dalam panduan ini ada gaya yang disebut folder-by-feature, alih-alih folder-by-type, dan saya sebenarnya penasaran apa pendekatan terbaik (dalam contoh ini untuk Jawa)

Katakanlah saya memiliki aplikasi tempat saya dapat mengambil Users & Pets, menggunakan layanan, pengontrol, repositori dan objek domain ofcourse.

Mengambil gaya folder-by -....., kami memiliki dua opsi untuk struktur pengemasan kami:

1. Jenis folder

com.example
├── domain
│    ├── User.java
│    └── Pet.java
├── controllers
│    ├── UserController.java
│    └── PetController.java
├── repositories
│    ├── UserRepository.java
│    └── PetRepository.java
├── services
│    ├── UserService.java
│    └── PetService.java
│   // and everything else in the project
└── MyApplication.java

2. Folder-by-fitur

com.example
├── pet
│    ├── Pet.java
│    ├── PetController.java
│    ├── PetRepository.java
│    └── PetService.java
├── user
│    ├── User.java
│    ├── UserController.java
│    ├── UserRepository.java
│    └── UserService.java
│   // and everything else in the project
└── MyApplication.java

Apa yang akan menjadi pendekatan yang baik, dan apa argumen untuk melakukannya?

Folder-per-tipe hanya berfungsi pada proyek skala kecil. Folder-by-feature lebih unggul di sebagian besar kasus.

Folder-by-type ok ketika Anda hanya memiliki sejumlah kecil file (di bawah 10 per jenis katakanlah). Segera setelah Anda mendapatkan banyak komponen dalam proyek Anda, semua dengan banyak file dari jenis yang sama, akan sangat sulit untuk menemukan file yang sebenarnya Anda cari.

Oleh karena itu, folder-by-fitur lebih baik karena skalabilitasnya. Namun jika Anda folder oleh fitur Anda akhirnya kehilangan informasi tentang jenis komponen file mewakili (karena tidak lagi dalam controllerfolder katakanlah), jadi ini juga menjadi membingungkan. Ada 2 solusi sederhana untuk ini.

Pertama, Anda dapat mematuhi konvensi penamaan umum yang menyiratkan ketelitian dalam nama file. Misalnya panduan gaya AngularJS populer John Papa memiliki yang berikut:

Pedoman Penamaan

• Gunakan nama yang konsisten untuk semua komponen mengikuti pola yang menggambarkan fitur komponen lalu (secara opsional) tipenya.
  Pola yang saya rekomendasikan adalah feature.type.js. Ada 2 nama untuk sebagian besar
  aset:

  • nama file (avengers.controller.js)
  • nama komponen terdaftar dengan Angular (AvengersController)

Kedua, Anda dapat menggabungkan gaya folder-per-jenis dan folder-per-fitur ke dalam folder-per-fitur-menurut-jenis:

com.example
├── pet
|   ├── Controllers
│   |   ├── PetController1.java
|   |   └── PetController2.java
|   └── Services
│       ├── PetService1.java
│       └── PetService2.java
├── user
|   ├── Controllers
│   |   ├── UserController1.java
│   |   └── UserController2.java
|   └── Services
│       ├── UserService1.java
│       └── UserService2.java

Ini benar-benar tidak ada hubungannya dengan teknologi yang dimaksud, kecuali jika Anda menggunakan kerangka kerja yang memaksa folder-jenis pada Anda sebagai bagian dari pendekatan konvensi-konfigurasi.

Secara pribadi, saya sangat berpendapat, bahwa folder-by-fitur jauh lebih unggul dan harus digunakan di mana-mana sebanyak mungkin. Ini mengelompokkan kelas-kelas yang benar-benar bekerja bersama, sedangkan folder-dengan-tipe hanya menduplikasi sesuatu yang biasanya sudah ada dalam nama kelas.

Bekerja dengan paket-per-fitur menonjol dalam modularitas dan kohesi yang tinggi . Hal ini memungkinkan kita untuk bermain dengan ruang lingkup komponen. Sebagai contoh, kita dapat menggunakan pengubah akses untuk menegakkan LoD dan inversi dependensi untuk integrasi atau ekstensi.

Alasan lainnya adalah:

• Navigasi kode yang lebih mudah
• Tingkat abstraksi yang lebih tinggi
• Minimalkan cakupan (pembatas konteks)
• Modularisasi vertikal

Folder-by-layer memberi terlalu banyak penekanan pada detail implementasi , (seperti yang disebutkan @David) apa yang tidak banyak bercerita tentang aplikasi yang sedang kami kerjakan. Tidak seperti package-by-feature , package-by-layer mendorong modularisasi horizontal. Modularisasi semacam ini membuat bekerja dengan komponen lintas sektor menjadi sulit dan membosankan.

Akhirnya, ada opsi ke-3. " Paket demi komponen " yang, dalam kata-kata Paman Bob, tampaknya lebih selaras dengan prinsip-prinsip paketnya . Jika pendapat Paman Bob penting atau tidak, saya serahkan pada Anda untuk memutuskan. Saya merasa menarik karena konvensi ini selaras dengan Arsitektur Bersih-nya, yang saya suka.