5

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

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>
    |____ ...

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

私たちのチームは聖戦を開始しました：最善のアプローチは何ですか。誰かが私たちを助けて、最初と2番目のものの短所と長所を説明できますか？たぶん、私たちの両方にとってより有用で有益な3番目のものがあります。

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

4

1 に答える 1

5

長寿命のアプリケーションを維持するために、2番目のオプションを選択します。

例を挙げて説明しましょう。

アプリケーションのリリースから1年後、元のコードを作成したチームが去ってから数か月後のある日、ユーザーは特定のプロセスでバグを検出して報告します。チケットは確かに「これは機能しません」のようになります。これは、いくつかの電子メールのピンポンの後、「オーストラリアの顧客の複数の製品の注文を保存できません」という結果になります。

最初のプロジェクト構造では、バグのあるコードがあるすべてのプロジェクトリクエストハンドラーとイベントハンドラーを検索する必要があります。2つ目では、注文保存モジュール（または構造の粒度に応じて「海外/複数製品の注文保存」モジュール）で検索を絞り込むことができます。

それは多くの時間を節約し、保守性IMOを容易にすることができます。

于 2010-11-10T17:31:35.553 に答える