原文：[https://dzone.com/articles/we...]
翻譯：祝坤榮

現在是時候停止像初學者教程裡教你的那樣來組織程式碼了。
​

現在，你應該在工作程式碼中捕捉領域知識並保護你的上下文不會被其他的知識上下文所汙染。ProductRepository與BasketRepository有什麼共同點？並沒有。是在處理不同的問題，所以為什麼把他們放在一起？
​

Product，ProductServie，ProductRepository是高度耦合的；為什麼不把他們放在一起？他們是個整體 - 程式碼是一起變動的，並放在一起，精心的封裝。越嚴格的限制你的存取級別，越能保證更少的機會出現不必要的依賴導致最後程式碼變成一鍋粥。
​

我們要頂住把任何東西都變成public的誘惑！那是程式碼庫變成一坨內部互相依賴的物件的原因。好好阻止你的包很重要。包中應該包含所有特定領域/上下文的類而且只提供一個特定的介面提供給其他的包來訪問。然後，不像以前那樣給每個類的每個公共方法寫單元測試，而是隻聚焦在元件的公共介面來寫單元測試，覆蓋所有的方法邏輯。[點這裡看我關於有效測試的文章]
​

有單一，良好定義目的的元件是很容易理解和閱讀的。元件的名稱清晰的宣告瞭他們的目的。
​

最基本的故事就是如果你的架構意圖明顯的對映到了程式碼上，可以讓其更容易理解和維護。你的程式碼應該能反映出你畫出的架構圖。
​

一致性與耦合

在一起變化的程式碼應該放在一起。為一個共同目標服務的程式碼應該放在一起。一致性是個很簡單的概念，我希望你也理解這點。
​

耦合是下一個重要的需要學習的內容。他是關於一個元件如何依賴或與另一個元件進行互動的。
(img)
一般來說，我們應該聚焦在高內聚和低耦合。通過高內聚實踐單一職責原理。通過良好定義的介面來反轉控制實現低耦合。
​

低耦合意味著跨元件間有更少的內部互動。他意味著一個元件在變更或替換時不會影響其他元件。
​

當軟體被分解成更小的元件，這些元件不可避免的會與其他元件有互動，這需要清晰定義的邊界來保證不會洩露領域。最終系統可以保持一致的互動但又彼此獨立，邊界分明。
​

這個故事最基本的內容就是如果我們可以在開發時有效的畫出並實施邊界可以讓系統更容易理解和閱讀。
​

演示

我寫了一個使用模組化原則自己設計和實現了單體應用的工程。[點這裡獲取]。我也錄了一個視訊來說明工程中在文章裡討論的部分。
​
https://www.bilibili.com/vide...
​

本文來自祝坤榮(時序)的微信公眾號「麥芽麵包，id「darkjune\_think」
轉載請註明。

交流Email: zhukunrong@yeah.net
微博:祝坤榮
開發者/科幻愛好者/硬核主機玩家/業餘翻譯