根據意圖而不是架構構建程式 - Janos Pasztor

banq發表於2019-01-09
架構

在檢視程式碼時，我經常會看到MVC模式：模型，檢視，控制器，表單等資料夾。表面上看起來不錯，對嗎？您將控制器放在控制器資料夾中，模型資料夾中的模型等等。這對於像部落格這樣的小型示例應用程式來說相當不錯，因為您可能有5個控制器，6個模型等等。
但是，當您在更大的應用程式上工作，或者您遵循一個控制器的概念 ，一個action時，這些資料夾中的這些檔案數量會迅速升級，併成為命名問題的混亂。
推薦談話： 羅伯特“鮑勃叔叔”馬丁 - 建築：失落的歲月
我們來看一個社交媒體專案的例子。你有Walls，WallPosts，評論，PrivateConversations， PrivateConversationMessages以及更多東西。使用“經典”排列，我們將擁有相當大的目錄樹，即使沒有前面提到的方法：

SRC
調節器
WallController
WallPostController
CommentController
PrivateConversationController
PrivateConversationMessageController
模型
WallModel
WallPostModel
CommentModel
PrivateConversationModel
PrivateConversationMessageModel
檢視

...

這只是一個簡單的例子，在現實世界中的應用程式，你就會有很多更多的控制器，模型和檢視。如果根據應用程式的構造（模型，檢視，控制器）進行構建，則在某個奇點之後，目錄結構將變得完全無法使用。
當然，您可以使用IDE的搜尋功能，但是過載的目錄結構會導致您感覺有太多的類。這種感覺反過來導致害怕新增新類，您的開發人員會嘗試將新功能填充到現有類中，即使它不嚴格屬於那個類，從而導致很多單一責任原則違規。此外，這種結構使得團隊中的新開發人員難以瞭解什麼是什麼。

基於意圖的結構
如果我們仔細觀察我們的控制器，我們可以在屬於一起的東西和不屬於哪些東西之間繪製線條。例如，從商業角度來看，Wall似乎是一個非常明確的概念：人們可以擁有一面牆，在上面寫帖子和對所述帖子發表評論。因此，讓我們將與牆相關的所有內容放入一個資料夾中。類似：

[b]src[/b]
<p class="indent">[b]wall[/b]
CommentController
CommentModel
WallController
WallPostController
WallModel
WallPostModel
<p class="indent">[b]conversation[/b]
PrivateConversationController
PrivateConversationModel
PrivateConversationMessageController
PrivateConversationMessageModel
...

仍然不是很好，但更好。現在可以擴充套件目錄結構而不必擔心太多的類，如果我們正在尋找一些東西，我們可以在哪裡找到它。
在我們繼續之前，讓我們澄清一件事：這些“模組”不是獨立的。有時，如果您希望單獨釋出模組，它們可能具有可能需要解決的交叉依賴性，但這是另一篇文章的主題。
您可能會注意到，現在模組中的所有內容都被拿出到另外一個目錄中。這很好，因為它（希望）會阻止你在一個模組中新增太多東西。但是，如果你像我一樣，你仍然喜歡有一些結構構建塊，所以讓我們帶回以前的目錄結構，但是低一級：

SRC
wall
 控制器 
   CommentController
   WallController
   WallPostController
模型
  CommentModel
  WallModel
  WallPostModel
檢視
...
會話
...


易於瀏覽和易於閱讀的程式碼塊。當然，您可以在您感覺舒適的同時，以層次結構的方式繼續新增業務結構。我建議你將它保持在3-5級以下，以便輕鬆導航。

提示： MVC不適合作為您的總體設計模式。相反，我建議看一下 Entity-Boundary-Interactor

總而言之，您最外層的資料夾結構應該基於業務概念（意圖），而不是您選擇使用的設計模式。​​​​​​​

相關文章