分層原則

在過去幾天，我參加了由 Jimmy Nilsson 主持的挪威企業軟體工作坊。在工作坊中，我們舉行了一場會議，提出並投票表決了一系列設計原則。

規則如下。每個人都可以提出良好的分層原則，並將其新增至清單中。原則的討論很少，僅在需要時進行澄清。人們可以提出他們喜歡或不喜歡的原則，規則是記錄人們在該領域聽到的原則。

我們取得清單後，便開始投票。我們使用了一種 點票法 的變體，每個人獲得 10 票正票和 10 票負票。

我將結果列在下方，原則後接以正負票數的格式。

• 層之間的低耦合，層內的高內聚。10/0
• 關注點分離。11/0
• 層應該與消費者無關（層不應該知道誰在它上面。）4/4
• 適應性：能夠改變。2/0
• 使用者介面模組不應該包含任何商業邏輯。10/0
• 商業邏輯層不包含任何使用者介面，也不參考使用者介面模組。8/0
• 層之間沒有循環參考。8/0
• 至少有三個主要層類型：簡報、網域和資料來源。3/9
• 商業層僅使用技術服務的抽象。14/0
• 按層分開開發團隊。1/22
• 層應該可以個別測試。12/0
• 優先讓層僅與相鄰層互動。4/4
• 層應該小心將較低層暴露給較高層。1/0
• 層應該將較低層隱藏在較高層。
• 層應該僅與相鄰層互動。2/3
• 變更較低層級的介面不應該變更較高層級的介面。2/5
• 在層邊界分配 0/18
• 層是一種邏輯人工製品，並不表示層之間的分配。11/0
• 較低層不應依賴較高層。6/0
• 每一層都應有秘密。3/2
• 各層應對其內部保持低調。8/0
• 各層應可互相替換。2/0
• 各層可以有多個相鄰的較高層。2/1
• 始終以服務層封裝網域邏輯。4/5
• 在層級邊界重新擲回例外。0/15
• 各層應可獨立維護和版本化。2/0
• 各層應有獨立的部署單元（例如，每個層的獨立 jar 或組件）。0/7
• 各層可以共用基礎架構層面（例如，安全性）。7/0
• 網域層不應與外部系統通訊，服務層應負責此工作。2/3
• 入站外部介面模組（例如，網路服務處理常式）不應包含商業邏輯。10/0

顯然地，您無法過度解讀此清單。雖然這群人很優秀，但他們絕非企業開發專業知識的權威來源。這些原則的措辭也有些鬆散，而且存在重疊和不精確之處，如果我們有超過一小時的時間進行練習，就能夠加以釐清。不過，我認為此清單可能會引發一些思考和討論。

我詢問人們是否有令他們驚訝的事項。有些人驚訝於他們經常聽聞（且不喜歡的）原則在投票中被否決。（依層級區分獨立的開發團隊和在層級邊界重新擲回例外。）同樣地，儘管「商業層僅使用技術服務的抽象概念」在實務上很少見，但它獲得了很高的票數，這也令人驚訝。