透過一個例子講解架構設計。假設正在構建一個線上書店，這個例子的任務就是實現一個客戶檢視訂單狀態的用例。我們可以看看如何進行程式碼設計和程式碼架構。
1。1 按層封裝
也許我們第一個想到的是傳統的水平分層架構，將程式碼從技術角度進行分類。其UML圖如下：
在分層架構中，Web程式碼分一層，業務邏輯分一層，持久化分一層。在java中，分層的概念是透過包來表示的。這種架構在專案初期很合適，因為不會過於複雜。但是軟體規模擴充套件了，程式碼分為三大塊並不夠，需要進一步的模組化。還有一個問題就是，分層架構無法展現具體業務領域資訊。
1。2 按功能封裝
還可以按照功能封裝，即垂直切分，根據相關功能、業務概念或者聚合根來切分。常見的實現就是把所有的型別都放在一個相同的包中，以業務概念來命名。
如上圖所示，類和介面和之前類似，只是他們都被放到同一個Java包中。這樣程式碼結構至少與業務領域有點相關了。另一個好處是，如果需要修改“檢視訂單”業務用例，比較容易找到相關程式碼，畢竟他們都在一個包中，而不是分散在各處。
通常軟體團隊一開始採用分層架構，在遇到困難後再切換到垂直分層方式。不過還有更好的分類方式。
1。3 埠和介面卡
透過採用“埠和介面卡”“六邊形架構”“邊界、控制器、實體”等，可以創造一個業務領域程式碼與具體實現細節（資料庫、框架等）隔離的架構。即可以區分出程式碼中的內部程式碼（領域，Domain）與外部程式碼（基礎設施，Infrastructure）。
其UML圖如下：
這裡的com。mycomapny。myapp。domain包是內部程式碼，另外兩個包是外部程式碼。注意依賴關係是由外向內。之前的OrdersRepository類改成了Orders。這個概念基於領域驅動設計概念，其中要求內部程式碼都應該用獨特的領域語言來描述。也就是說，在業務領域裡討論的是“Orders”，而不是“OrdersRepository”
1。4 按元件封裝
按元件封裝混合了前面的方法，目標是講一個粗粒度元件相關的所有類放入一個java包中。這就像是一種面向服務的視角來構建軟體系統，類似微服務架構。就像埠和介面卡模式將Web視為一種互動手段，“按元件封裝”將UI與粗粒度元件分離。如下圖：
總的來說，這種方式將“業務邏輯”與“持久化程式碼”合併在一起，稱為“元件”。元件的定義：元件是部署單元，元件是系統中能夠部署的最小單位，對應在java裡就是jar檔案。
“安元件封裝”的好處是，如果我們需要編寫和訂單有關的程式碼，只有一個位置需要修改——OrdersComponet。在這個元件中，仍然應該關注重點隔離原則。
1。5 具體實現細節中的陷阱
表面上看，四種程式碼組織方式各不相同，可以認為是不同的架構設計風格。可是如果具體實現中不嚴加註意，很快就會出現偏差。
經常碰到的一個問題是，java中濫用public修飾符。如果將所有的類都設定為public意味就無法利用程式語言提供封裝手段。這樣就沒有任何東西可以阻礙某人寫一段直接初始化具體實現類的程式碼，哪怕違反了架構設計原則。
1。6 組織形式與封裝的區別
從另一個角度看，如果將java程式中所有的型別都設定為public，那麼包就僅僅是一種組織形式，而不是一種封裝方式。由於public型別可以在程式碼庫的任何位置呼叫，那事實上就可以忽略包的概念。最終如果忽略包的概念，那麼想要採用的任何架構風格就不重要了。
