很多軟件團隊用分層來結構化他們的代碼。換句話說，如果你打開一個代碼庫，就會看到域類包、UI素材包、「業務服務」包、數據訪問包、集成包等。這裡我用了「包」這個Java術語，但同樣適用於C#的命名空間，等等。
原因很簡單。我們知道，架構分層一般都是「好事」，很多教程都把這種封裝風格作為結構化代碼的方法來教授。舉個例子，如果你用谷歌搜索Spring或ASP.NET MVC的相關教程，就會在示例代碼中看到這一點。我的職業生涯大都花在用Java構建軟件系統上，在參與過的大多數項目中，我也用同樣的封裝方法。
這種封裝代碼的方法儘管沒有什麼錯，代碼結構卻從未反映出我們從架構角度看這個系統時考慮的抽像。如果使用一種面向對象的編程語言，你在討論架構時會談論「對像」嗎？以我的經驗來看，答案是否定的。我聽到的往往是組件和服務之類的概念，結果架構圖中的「組件」實際上是由多個層上的類組合實現的。比如，你可能會發現一個組件有一部分 在「服務」包裡，其他部分則在「數據訪問」包裡。
用層封裝
為了做到這一點，較底層的代碼（比如「數據訪問」包）往往是公開可見的，這意味著它也能被架構中的其他層直接調用。