架構（結構）取向與面向特徵的項目結構

Question

的項目，我也參與其中，有一個面向服務架構項目的文件/文件夾結構：

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

這種變異是接近的設計師和它清楚地描述了實現的功能。

我們的團隊已經開始了一場聖戰：什麼是最好的方法。 有人可以幫助我們解釋缺點和優點的第一個和第二個。 也許有第三個對我們兩個人更有用和有益。

謝謝。

Answer 1

我會選擇第二個選項，以便長壽命應用程序的可維護性。

讓我用一個例子解釋：

有一天，在應用發佈後一年，和幾個月誰又寫道原代碼球隊已經離開後，用戶檢測並在一定的工藝報告bug 。該票肯定會看起來像「這東西不起作用」，在一些電子郵件乒乓後，它將最終成爲「我不能爲澳大利亞客戶保存多產品訂單」。

那麼，在第一個項目結構中，您必須在所有項目請求和事件處理程序中搜索出錯代碼。 第二個，您可以在訂單保存模塊（或根據您的結構粒度，「海外/多產品訂單保存」模塊）縮小搜索範圍。

它可以節省大量的時間，並減輕IMO的可保持性。