アーキテクチャ(構造)指向と機能指向のプロジェクト構造


14

私が関与したプロジェクトには、アーキテクチャ指向のプロジェクトのファイル/フォルダー構造があります。

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

システムのアーキテクチャの観点から明らかです(開発チームによって提案されています)。

デザイナーチームによって提案された機能指向の構造です。

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

このバリアントは設計者により近く、実装する機能を明確に説明しています。

私たちのチームは神聖な戦争を始めました:最善のアプローチは何ですか。誰かが私たちを助けて、1番目と2番目の長所と短所を説明できますか?多分私たちの両方にとってより有用で有益な3番目のものがあります。

ありがとうございました。


私はどちらの構造も理解していません-イベントとリクエスト(そしてイベントハンドラーとリクエストハンドラー)の違いは何ですか?
ピーターボートン

1
非常に明確な質問-そして中立も!
マイケルK

1
スケーラビリティの観点からは、2番目のアプローチは水平方向にスケールアウトするのがかなり簡単です。
CodeART

回答:


11

私は2番目に投票します。最初の構造では、のイベントハンドラはのイベントハンドラとFeatureAはまったく関係ありませんFeatureB。開発者は一度に1つの機能に取り組んでいるようです。FeatureXリクエストに取り組んでいる場合、FeatureXリクエストよりもリクエストハンドラを微調整する必要がある可能性がはるかに高くなりますFeatureZ

ところで、私はあなたが中立的な観点からこの質問をどのようにしたかが大好きです。


1
+1の注意点が1つあります。小規模なプロジェクトの場合、2番目のプロジェクトでは、配置するファイルよりもファイル構造が大きくなります。1番目のファイルを使用します。
マイケルK

@マイケルは同意しますが、この場合は大規模なプロジェクトです。
Zzz

1
+1:また、ユーザー/クライアントと会話する必要がある場合、用語はかなり一貫している可能性があります。
スティーブンエバーズ

4

私は常に2番目のアプローチに慣れていますが、真の共有/ベースクラスには、一般または共通と呼ばれる「機能」が常にあります。

アプローチ2では、真に別々のものを分離しますが、「共通」領域がないと、物事がうまく適合しない領域に分離することがあります。


一般的および一般的な+1(すべてのプロジェクトに一般的なユーティリティ、ツールがあります...)
Zzz

3

機能発明者が実装の詳細を気にするのはなぜですか?それが議論の側面間の分離である場合、私は答えが明確だと思います。アイデア/機能を発明する人々は、実装者が必要とするファイル構造を決定しません。

これは、機能の実装が複数のdll、exe、データベース、またはその他のソフトウェアに及ぶ場合に特に重要な問題です。


1
私はそれについて考えましたが、他のすべてが等しい場合、2番目のアプローチには、最も些細なアプリケーションを除くすべてのアプリケーションに対して明確な哲学的利点があります。少なくとも、それは良い提案です。
ロバートハーベイ

@Robert Harvey:プロジェクトのアイデア構成について話している場合、新しい答えを考え出す必要があります。彼らは...コードを含むファイルの話をしているようしかし、それが聞こえる
ジョン・フィッシャー

重要なのは、機能を個別のバケットに分離することです。最小のアプリケーションを除いて、フォルダー構造、クラス構造、または名前空間規則を参照するかどうかにかかわらず、このような組織が必要になります。
ロバートハーヴェイ

1
@Robert Harvey:ビルドとデプロイの問題はどうですか?IDEを使用してコードを記述およびデバッグするだけの単純なものはどうですか これらのいくつかは、フォルダー構造に強力な影響を与えるはずです。
ジョンフィッシャー

1

2つの選択肢があるため、2番目のアプローチに同意する必要があります。最初のものは不定形のブロブのように見えます。少なくとも2番目のものは何らかの形をしています。

これは、プロジェクトの規模に大きく依存します。「機能」が大きい場合、それぞれに個別のバケットが必要です。


1

私はあなたが使用している用語を理解していませんが、両方の構造が間違ったアプローチのように見えるので、とにかく答えようとします。

一握りの機能しか持っていない場合は、それらをカテゴリにグループ化する必要があります-そして、それはどちらの設計にも対応していないようです(Node1が意図しているものでない限り、それ以外の場合、そしてそれはWTFだと思うようになります-Node2はありますか?)

私はこのようなものを検討するかもしれません:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

またはこれ:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events


しかし、彼らは両方とも完全に外れているかもしれないという仮定を立てています-あなたが質問をより詳細に更新できるなら、私は私の考えを変えるかもしれません。:)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.