フォルダーをビジネスドメインごとに、または技術ドメインごとに整理する必要がありますか？

たとえば、MVCのようなアーキテクチャを使用している場合、どのフォルダー構造を使用する必要がありますか。

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

または：

controllers/
    domain1
    domain2
models/
    domain1
    domain2
views/
    domain1
    domain2

この質問を言語にとらわれないようにするために、ファイル拡張子を意図的に省略しました。

個人的には、ビジネスドメイン（直感）ごとに分離したいのですが、ほとんど/多くのフレームワークは技術ドメインごとに分離されています。なぜ私が一方をもう一方よりも選ぶのですか？

これは特定のプロジェクトに依存すると思います。

たとえば、異なるビジネスドメインが互いに完全に独立している場合、ビジネスドメインごとに整理します。

しかし、ビジネスドメイン間で共有コードがある場合、またはビジネスドメインが同じコードベースの異なるバリアントである場合は、技術ドメインごとに整理する方が論理的です。また、何らかのオブジェクト指向言語を使用する場合は、ビジネス固有のファイルで汎用コントローラー、モデルなどをサブクラス化して、より薄くすることができます。

また、2つの中間（ゴールデン）があります-共有コードを独自のドメインに取り除き、それを他のドメインで使用します。これにより、直感的に操作できるレイアウトが得られますが、ビジネスドメイン間でコードを共有できます。

Domain1              # This domain changes bits of standard MVC code
  controllers
  models
  views
Domain2              # this domain only modifies views, all else is standard
  views
Shared               # Here is the better part of code base
  controllers
  models
  views

PS。ほとんどのフレームワークは、コードを共有していない場合に別のプロジェクトを作成する場合にのみ、異なるビジネスドメインを単一のプロジェクトに混在させることを期待する傾向があるため、技術ドメインごとに整理すると思います。

編集：

たとえば、会社の倉庫を処理するWebアプリがあるとします。一般的な形では、これは多くの企業に当てはまるかもしれませんが、それぞれが満たしていない特定の詳細を持っている可能性があります。たとえば、彼らの一人はフォークリフトにタブレットを展開し、アイテムをデフォルトの2レベルではなく3レベルに整理します。

もちろん、これらの会社ごとにプロジェクトを分岐できます。ただし、フレームワーク/言語で許可されている場合は、サブクラス化やプラグインなどを使用して、汎用プロジェクトの断片をすべての顧客のニーズに合わせてカスタマイズし、ビジネスドメインレイアウトで整理できます。

たとえば、汎用プロジェクトがJSONにアイテム自体のみをエクスポートする場合、Domain1はコントローラーをサブクラス化し、最近の配信の問題もエクスポートすることができます。

また、後でDomain1にDomain2にも有効なコンポーネントがあることがわかった場合、その汎用バージョンをSharedに抽出できます。

あなたが言ったように、多くのフレームワークは技術的なドメインごとに整理されており、私が選んだFWがこれを簡単にするという理由だけで、私は今のところそれを使用しています。しかし、少し（または大量の）エルボグリスで、インクルードパスを書き換えてビジネスドメインレイアウトもサポートできると思います。

「定期的に、より多くのドメインまたはより多くの技術部門を追加する可能性が高いのは何ですか」と尋ねることは啓発的だと思います。それから答えが何であれ、それをトップレベルに置いてください。

ほとんどの場合、技術アーキテクチャはドメインよりも速く固化します。つまり、最初にドメインごとに、次にアーキテクチャコンポーネントごとに整理する必要があります。その理由は、ドメイン内の何かが変更された場合、そのドメイン内の複数の技術コンポーネントを追加または変更する必要があるかもしれませんが、それがローカライズされ、他のドメインにあまりあふれないことを願っています。

GUIフレームワークを変更した場合、その変更はアプリケーション全体に波及しますが、GUIフレームワークはほとんど変更しませんが、ドメインロジックは常に変更します。

同時に変化する可能性がある場合は、物をまとめてください。

別の選択肢があり、それはプラグインの別の部分を移動しています。たとえば、CakePHPがそれを行います。再利用可能な完全なMVCパーツを生成し、必要なロジックでソートできます。

メインアプリケーションはそれらを使用し、それらにリンクします。

基本的に、あなたの質問は凝集と結合についてです。個別のパーツを可能な限り独立して機能させたい場合。そうすれば、テスト可能かつ再利用可能なコードを取得できます。

それを考慮に入れる：ドメインごとに分割する場合、アプリケーションの一部をどのように再利用しますか？たとえば、Webショップを利用します。/orders/view/1のリクエストが送信されるため、注文番号を表示する必要があります。1. / orders / controllers / order_controllerに移動します。製品と注文でドメインを分離している場合は、すでに他の「ドメイン」の一部が必要です。

そこから物事のインターフェイスを開始できますが、ほとんどのビジネスでは物事はまとまりすぎています。技術的なアプローチをとる場合。たとえば、注文を処理するプラグインを使用できます。中央アプリケーションからProductオブジェクトをそこに入れます。そうすれば、プラグインを簡単にテストでき、名前と価格でProductオブジェクトを作成して送信するだけです。

プラグインは、必要なことを正確に行います。他の「パーツ/ドメイン/エリア」ではなく、その入力に依存します。

Microsoft ASP.Net MVC 3には「エリア」の概念があります。MVCプロジェクトに「エリア」を導入すると、次のように分割されます。

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

これは非常に自然なことでした。エリアはプロジェクトの「大きな塊」であり、自己完結型のユニットで作業することは非常に理にかなっています。

一致させる名前空間FWIWを使用しました。

30万行のコードで構成されるWebショップでの私個人の経験から、私は常にビジネスドメインごとに整理を行います。この方法では、1つの機能分野で作業するときに、関連するすべてのクラスの簡単な概要を取得できるだけでなく、Javaでもパッケージの可視性を利用できます。

興味のある人向けの詳細：5年前にプロジェクトが開始されたとき、開発者は次のパッケージ構造を作成しました。

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

ショッピングカート、製品検索などの各ショップ機能は、それぞれ独自のフォームクラス（MVCフレームワークで義務付けられている構造）を持つ複数のアクションで構成されています。最終的にアクションパッケージには200を超えるクラスがあり、それぞれが関連するフォームクラスから完全に分離されています。さらに悪いことに、アクションはあまり多くのロジックを実装せず、別のパッケージにある関数固有のサービスを呼び出します。

チームに提案して、ビジネスドメインごとにパッケージを整理することに切り替えるべきだと確信しました。理由は簡単です。すべてのアクションのリストを本当に見たい場合は、適切なIDEのタイプ階層ビューを開くだけです。ただし、IDEができないことは、クラスが属するビジネスドメインを推測することです。さらに、このアプローチにより、いくつかの機能に必要なクラスのみを公開し、残りをパッケージの可視性に保つことができます。

多くのフレームワークは技術ドメインごとに分かれていることに同意します。そのため、新しいフレームワークを使用するときにこの方法から始めることがよくあります。しかし、私は一貫して、フォルダードメインの主要なレベルとしてビジネスドメインを使用することに決めています。

個人的には、Fooの周りに機能を追加するときに頻繁に両方の作業を行う必要があるため、コントローラーのフォルダーとリポジトリのフォルダーを行き来するよりも、FooコントローラーとFooリポジトリーなどを一緒に保持する方がはるかに簡単だと思います。大規模なプロジェクトでは、技術フォルダー間の距離が大きくなり、開発中の顕著な時間の無駄になる可能性があるため、これはさらに重要です。