Я використовую посібник зі стилю AngularJS. У цьому посібнику є стиль, який називається folder-by-feature, а folder-by-typeне мені цікаво, який найкращий підхід (у цьому прикладі для Java)

Скажімо, у мене є додаток, де я можу отримати користувачів і домашніх тварин, використовуючи сервіси, контролери, сховища та об'єкти домену курсу.

Беручи до стилів папки -....., ми маємо два варіанти для нашої структури упаковки:

1. Папка за типом

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. Папка за ознакою

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

Який був би гарний підхід і які аргументи для цього зробити?

Папка за типом працює лише для малих проектів. У більшості випадків папка за особливістю є кращою.

Типова папка в порядку, коли у вас є лише невелика кількість файлів (менше 10 на тип дозволяє сказати). Як тільки ви отримаєте кілька компонентів у вашому проекті, усі з кількома файлами одного типу, вам стає дуже важко знайти фактичний файл, який ви шукаєте.

Тому папка за функцією краще завдяки своїй масштабованості. Однак якщо ви створюєте папку за функцією, ви втрачаєте інформацію про тип компонента, який представляє файл (оскільки його більше немає в controllerпапці), тому це теж стає заплутаним. Для цього є 2 простих рішення.

По-перше, ви можете дотримуватися загальних умов іменування, які передбачають тип у назві файлу. Наприклад, популярний посібник зі стилю Джона Папи щодо AngularJS має таке:

Назви керівництва

• Використовуйте узгоджені назви для всіх компонентів, слідуючи шаблону, який описує особливість компонента, а потім (необов'язково) його тип. Мій
  рекомендований зразок - feature.type.js. У більшості
  активів є 2 назви :

  • ім'я файлу (avengers.controller.js)
  • ім'я зареєстрованого компонента з кутовим (AvengersController)

По-друге, ви можете комбінувати стилі папок за типом і папки за ознакою в папку за характеристикою:

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

Це насправді не має нічого спільного з розглянутою технологією, якщо ви не використовуєте рамку, яка змушує застосовувати папку за типом як частину підходу конвенції над конфігурацією.

Особисто я переконаний, що папка за характеристикою набагато краща і її слід використовувати скрізь якомога більше. Він об'єднує класи, які фактично працюють разом, тоді як папка за типом просто копіює те, що зазвичай вже присутнє у назві класу.

Робота з пакетами за особливістю виділяється високою модульністю та згуртованістю . Це дозволяє нам грати із сферою використання компонентів. Наприклад, ми можемо використовувати модифікатори доступу для забезпечення LoD та інверсії залежності для інтеграцій або / та розширень.

Інші причини:

• Легша навігація кодом
• Більш високий рівень абстракції
• Мінімізуйте сфери застосування (обмежуючі контексти)
• Вертикальна модуляція

Папка за шаром робить занадто великий акцент на деталях реалізації (як згадував @David), що не говорить занадто багато про додаток, над яким ми працюємо. На відміну від пакету за функцією , пакет за шаром заохочує горизонтальну модуляцію. Така модуляризація робить роботу з наскрізними компонентами важкою і виснажливою.

Нарешті, є 3-й варіант. " Пакунок за складовими ", який, за словами дядька Боба, здається, краще відповідає його принципам пакету . Якщо думка дядька Боба має значення чи ні, я залишаю це вам вирішити. Мені це цікаво, оскільки ця конвенція узгоджується з його чистою архітектурою, що мені подобається.