web-dev-qa-db-ja.com

タイプ別フォルダまたは機能別フォルダ

AngularJSスタイルガイドを利用しています。このガイドには、folder-by-featureではなくfolder-by-typeというスタイルがあり、実際には（Javaのこの例では）最善の方法は何なのか知りたいです。

サービス、コントローラー、リポジトリ、およびもちろんドメインオブジェクトを使用して、ユーザーとペットを取得できるアプリケーションがあるとします。

Folder-by -.....スタイルの場合、パッケージ構造には2つのオプションがあります。

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

良いアプローチとは何でしょうか、そうするための引数は何ですか？

project-structurepackages
63
Jelle

タイプ別フォルダは、小規模プロジェクトでのみ機能します。ほとんどの場合、機能別フォルダのほうが優れています。

タイプごとのフォルダーは、ファイルの数が少ない場合に問題ありません（タイプごとに10未満は言うことができます）。プロジェクトに複数のコンポーネントがあり、すべて同じタイプのファイルが複数あると、探している実際のファイルを見つけるのが非常に難しくなります。

したがって、スケーラビリティのため、機能ごとのフォルダーの方が優れています。ただし、機能ごとにフォルダーを作成すると、ファイルが表すコンポーネントのタイプに関する情報が失われることになり（controllerフォルダーには存在しないため）、これも混乱を招きます。これには2つの簡単な解決策があります。

最初に、ファイル名のタイプを意味する一般的な命名規則に従うことができます。たとえば、John Papaの人気のある AngularJSスタイルガイド には次のようになります。

命名ガイドライン

  • コンポーネントの機能を説明し、次に（オプションで）タイプを説明するパターンに従って、すべてのコンポーネントに一貫した名前を使用します。俺の
    推奨パターンは、feature.type.jsです。ほとんどの2つの名前があります
    資産：

    • ファイル名（avengers.controller.js）
    • Angular（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
73
David says Reinstate Monica

これは、コンベンションオーバーコンフィグレーションアプローチの一部としてタイプごとにフォルダーを強制するフレームワークを使用しない限り、問題のテクノロジーとはまったく関係ありません。

個人的には、機能別フォルダははるかに優れており、可能な限りあらゆる場所で使用する必要があるという意見に強く同意します。タイプごとのフォルダーは、通常、クラス名にすでに存在するものを複製するだけですが、実際に連携するクラスをグループ化します。

26
Michael Borgwardt

packages-by-featureでの作業は、高いモジュール性と凝集性で際立っています。これにより、コンポーネントのスコープを操作できます。たとえば、 アクセス修飾子 を使用して LoD と 依存関係の反転 を統合または拡張に適用できます。

その他の理由は次のとおりです。

  • 簡単なコードナビゲーション
  • より高いレベルの抽象化
  • スコープ（境界コンテキスト）を最小化する
  • 垂直モジュール化

Folder-by-layerは 実装の詳細に過度に重点を置いています 、（@ Davidが言及したように）アプリケーションについてあまり多くを伝えていないこと取り組んでいます。 package-by-featureとは異なり、package-by-layerは水平方向のモジュール化を促進します。この種のモジュール化により、分野横断的なコンポーネントでの作業は困難で面倒です。

最後に、3番目のオプションがあります。 " パッケージごとのパッケージ "は、ボブおじさんの言葉では、彼の パッケージの原則 とよりよく整合しているようです。叔父のボブの意見が重要かどうかは、私が決めるのはあなたに任せます。このコンベンションは私が好きな彼のクリーンアーキテクチャと整合しているので、面白いと思います。

17
Laiv