標籤：
討論設計時，專業詞彙滿天飛，每個人的技術背景、工作經驗上的不同都會導致在理解上存在著差異。無論是SEI的定義、OMG UML的定義、還有各路大神的定義，都有從不同視角帶來的差異。準備後面關注這些定義的差異，攤開來大家一起來討論。
關於’商務邏輯’, 國內國外爭論了很多年了(這篇在07年就說沒有清晰的定義)，其中幾個比較詳細的討論見附錄(一定要看評論)。我總結主要分為兩類: 一類是邏輯處理論，一類是資料操作論。
邏輯處理論先看前者，這一類觀點，核心是強調邏輯。 細說商務邏輯中,作者將商務邏輯分別做了狹義和廣義的定義，其中狹義定義如下:
商務邏輯就是對資料訪問操作的簡單的封裝 (顯然就是第二類觀點)而廣義的定義如下:
軟體產品由介面/互動與商務邏輯兩部分構成。商務邏輯是軟體產品的核心，但不與使用者互動。
後面這個廣義的定義好有力度，一刀從介面切開，一邊介面，另一邊就是商務邏輯。不過，這個也與國外一位大牛的定義呼應(What is Business Logic Anyway)，大意為: 一個應用中最為珍貴的核心所在，並不依賴於某個特定應用而存在。這裡面已經是從領域驅動設計的角度來看。介面可以理解為應用的展示層，而商務邏輯是領域模型的核心，代表了應用解決領域問題所應用的流程、公用、演算法、決策樹、各類方法、查詢等。
資料操作論而資料操作論，特彆強調操作資料，以Wiki為代表。先看一下Wiki的定義，略有點中間路線的味道，顯然是站在公司專屬應用程式的角度來定義：依據現實的商務規則來操作資料。(原文:In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, displayed, stored, and changed.)
還種觀點認為需要從”業務"的定義來理解商務邏輯。從需求出發，商務規則(Business Rules)是基本的業務需求，包括業務的管理、運算、以及處理資料等。實現時可以分為應用邏輯(application logic)和領域邏輯(domain logic), 這些都是商務邏輯。其中前者是處理一些非核心邏輯，比如ERP中訂單號產生的規則了。後面則是核心的邏輯，比如物料清單轉為請購單的處理。
另一個此觀點的變形，嘗試將商務邏輯與MVC/MVP中的Model關聯起來。但實際上MVC/MVP這種本身用於展現(GUI或console)的設計方案在有關商務邏輯的討論上顯得太狹義了。對於一些大型應用而言，MVC/MVP可能僅僅處於其中的展現層。
最後還有一層次上的視角問題。從應用的整體來看，和從單獨一個層次的角度來看，所謂的”業務"也是不同的。所以配合廣義論，商務邏輯就會變成一個無所不包的概念。那麼這個概念本身就變成了
內部處理的代名詞。商務邏輯這個概念本身起源於公司專屬應用程式的架構設計，未必能適用於整個軟體領域。所以，也有很多工程師從來不談”商務邏輯”。
總結曾經有人說過，任何普適的概念，和廢話一樣。從軟體的細節到整體，有著無數不同的視角。順暢的討論還是要從確定共同的視角開始。下次再討論時，如果覺察到關於商務邏輯的理解不同，還是先說清楚，你定義的業務和商務邏輯是什嗎？
參考：細說商務邏輯 (uml.org.cn)What is the heck is business logic anyway?What’s the difference between application layer and business logic layer? (SO)什麼是商務邏輯 (度娘)
歡迎一起學習、討論！
[架構設計] 什麼是商務邏輯
