還有一些原則是關於軟件結構應該如何安排的。比如下面這些。
- 分層策略 ：因為每一層都獨立於周圍，分層架構通常出現在有高度靈活性的軟件系統中。比如，你可以把軟件系統解構為UI（User Interface，用戶界面）層，業務層和數據訪問層。使業務層完全獨立於數據訪問層意味著（通常）可以實現在不影響業務或UI層的情況下切換數據訪問。能這樣做是因為數據訪問層向業務層呈現了抽像，而不是業務層自己直接處理數據存儲機制。如果想以這種方式安排軟件結構，你就應當確保開發團隊裡每個人都明白這個原則。「UI組件或域對像裡沒有數據訪問邏輯」是該原則在實踐中的一個具體例子。
- 業務邏輯的位置 ：有時候，出於性能或可維護性的原因，你要確保業務邏輯總是駐留在一個地方。對於連接互聯網的移動應用程序，你可能想要確保服務器盡可能多地處理發生的請求。或者如果你在整合一個已經包含了大量業務邏輯的遺留後端系統，可能想要確保團隊裡沒有人打算複製它。
- 高內聚、低耦合 、SOLID 1 等：有很多關注點分離相關的原則，專注於構建不需要太多依賴就能完成工作的高內聚的小結構單元。
- 無狀態組件 ：如果你在構建一個需要很強可伸縮性的軟件，那麼盡可能把組件設計得無狀態，就是一種確保可以通過複製組件來對系統進行橫向擴展從而分擔負載的方式。如果這是你的可伸縮性策略，每個人都需要明白他們必須使用相同的模式來構建組件。這有助於避免將來出現任何討厭的意外和可伸縮性瓶頸。
- 存儲過程 ：關係型數據庫的存儲過程就像馬麥醬2 ——你對它們不是愛就是恨。用不用存儲過程都各有優缺點，但當團隊只是選擇一種數據訪問的方法並堅持，我還是傾向於存儲過程。然而，每條原則都有例外。
- 域模型：豐富與貧瘠 ：有些團隊喜歡在自己的代碼中有很豐富的域模型，構建本質上非常面向對象的系統。另一些則傾向於更貧瘠的域模型，對像只是被粗粒度組件和服務使用的數據結構。方法的一致性有很長的路要走。
- HTTP會話的使用 ：如果你在構建一個網站，可能想或者不想用HTTP會話來存儲請求間的臨時信息。這通常取決於很多事情，包括你的伸縮策略是什麼，會話支持對像到底存儲在哪裡，服務器出現故障時會發生什麼，你是否使用粘性會話，會話複製的成本，等等。再次，開發團隊的每個人都應該明白想要的方法，並堅持下去。
- 始終一致與最終一致 ：很多團隊都發現，他們往往需要為滿足複雜非功能需求做出權衡。比如：有些團隊用數據一致性換取性能或可伸縮性。我們能看到所有的Facebook3 狀態更新，但是否都能立即看到真的重要嗎？你的語境將決定立即或延遲的一致性是否妥當，但一致的方法很重要。
1 http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
2 http://en.wikipedia.org/wiki/Marmite ，一種黏稠狀、深棕色並且有鮮明特色風味的醬，通常抹在麵包等食品上食用。——譯者注
3 http://facebook.com/ ，著名社交網站。——譯者注