應用系統-業務邏輯寫入在分層結構中Service層

近日，關於我們某同學在研發過程中一些設計問題，再次迴歸老生常談的問題：業務邏輯寫在哪兒一層？過去二十年軟件開發過程中，大部分開發者喜歡使用存儲過程(SP)，用SP解決一系列業務處理過程，在信息系統中時常聽到有SP的存儲。各大數據庫廠商也對存儲過程支撐較好。我過去已經反思過，是不是可以使用SP中直接構建HTML的字符串整合數據返回，實際上是可以做到的《Generating HTML from SQL Server Queries》。但真實軟件系統，我們可能不這麼做。系統各層職責也不清楚，誰負責數據存儲，數據展現，數據構建？本身前端需要完成的渲染VIEW事項，被數據庫完成了？這樣的弊端似乎更多。

如下經典的分層架構：

表示層：表示層處理HTTP請求，將JSON參數轉換爲對象，並對請求進行身份驗證，然後將其傳輸到業務層。簡而言之，它由視圖組成，即前端部分。

業務層：業務層處理所有的業務邏輯。它由服務類組成，並使用數據訪問層提供的服務。它還執行授權和驗證。

持久化層：持久化層包含所有的存儲邏輯，並將業務對象從數據庫行中翻譯出來。

數據庫層：在數據庫層中執行CRUD（創建、檢索、更新、刪除）操作。

對應我們JAVA中工程結構是這樣：

當時只有3層：表示層、持久層和服務層。服務層幾乎處理了所有事情。

爲了後期演化

1) 國產化數據庫適配
2) 業務邏輯的可測試性
3) SQL可維護性較弱，不同數據庫SQL少許差別
4) 工程轉型微服務架構

原因

可擴展性：業務邏輯在service層計算可以伸縮擴展，而在在sql中依賴數據庫server自己計算資源，是有限的，不容易擴展。數據量多時容易產生 slow log, 進而SQL優化，mysql數據庫本身有瓶頸。
可測試性：SQL 腳本少一個分號，只有整個工程啓動時，調用這個接口時才知道。在service層我們可以用單元測試。
系統支撐國產化數據庫，ARM架構
單元測試關注於 service層，不訪問數據庫，如業務邏輯在SQL 則測試覆蓋不到。接口測試代價較高。單元測試成本最低。

回顧常見問題

1. 業務邏輯寫入SQL是指 a字符轉換處理，b字符連接，c字段拼接，d自定義函數，e存儲過程
f多表join,

如這樣的SQL，使用GROUP_CONCAT

SELECT project.id AS id,
project.project_name AS project_name,
GROUP_CONCAT(DISTINCT param.param_name SEPARATOR '、') AS project_param,
GROUP_CONCAT(DISTINCT method.standard_name, ' ', method.standard_number SEPARATOR '、') AS project_method,
GROUP_CONCAT(DISTINCT domain.domain_code SEPARATOR '、') AS project_domain,
project.status AS status,
project.create_time AS create_time,
project.update_time AS update_time,
GROUP_CONCAT(DISTINCT link_person1, ':', link_phone1, ';', link_person2, ':', link_phone2) AS link
FROM t_ab_project AS project
LEFT JOIN t_ab_project_domain AS domain ON domain.project_id = project.id
LEFT JOIN t_ab_project_param AS param ON param.project_id = project.id
LEFT JOIN t_ab_project_method AS method ON method.project_id = project.id

事實情況在程序中處理有更高伸縮性。

2. 避免SQL中Join基礎表

將業務邏輯置於應用程序中，而非數據庫中

業務邏輯是應用程序的核心，它定義了應用程序如何執行其任務。但是，業務邏輯應該放在哪裏？許多開發人員會自然而然地將其置於數據庫中。畢竟，數據庫是數據的源頭，而業務邏輯往往涉及到數據處理。然而，這種做法是有問題的。將業務邏輯置於應用程序中，而非數據庫中，是更好的做法。以下是爲什麼：

數據庫的主要職責是存儲和保護數據。它們經過優化，以確保數據的完整性和可靠性。然而，它們並不是爲執行復雜業務規則而設計的。將業務邏輯置於數據庫中可能會導致混亂和難以維護的代碼。

另一方面，應用程序是爲處理業務邏輯而構建的。應用程序可以更容易地處理複雜的業務規則和數據驗證。此外，應用程序可以提供更好的用戶體驗，因爲它們可以更方便地與用戶界面和其他系統集成。

將業務邏輯置於應用程序中也可以提高代碼的可重用性。如果多個應用程序需要使用相同的業務邏輯，則可以將其封裝在共享庫中，而不是在每個應用程序中重複相同的代碼。

當然，這並不是說數據庫不應該參與業務邏輯的處理。事實上，數據庫觸發器和其他存儲過程可以在某些情況下非常有用。但是，這些應該作爲應用程序業務邏輯的補充，而不是替代。將業務邏輯置於應用程序中，而非數據庫中，是更好的做法。這可以提高代碼的可維護性、可重用性和整體質量。

將業務邏輯放在數據庫中的優缺點

優點

便於數據訪問：將業務邏輯放在數據庫中，可以方便地訪問和操作數據。這可以減少網絡延遲和數據傳輸的開銷，提高應用程序的性能。

原子性保證：數據庫事務可以確保數據的原子性，即在事務執行期間，數據要麼全部更新，要麼全部回滾。這可以保證數據的一致性。

簡化應用程序邏輯：將業務邏輯放在數據庫中，可以減輕應用程序的負擔，使其專注於用戶界面和用戶交互，而不需要處理複雜的數據處理邏輯。

缺點

難以維護：將業務邏輯放在數據庫中可能會導致代碼混亂和難以維護。數據庫不是爲處理複雜業務規則而設計的，因此可能會使代碼變得更加複雜和難以理解。

缺乏可重用性：如果多個應用程序需要使用相同的業務邏輯，將其放在數據庫中可能會導致代碼重複和難以維護。相反，將業務邏輯放在應用程序中，可以將其封裝在共享庫中，提高代碼的可重用性。

難以測試：對數據庫中的業務邏輯進行測試可能會比較困難，因爲需要模擬數據庫環境，並確保測試數據與生產數據一致。

結論

將業務邏輯放在數據庫中是有優缺點的，需要根據具體情況來決定是否合適。在以下情況下，將業務邏輯放在數據庫中可能是合適的：

數據訪問頻繁，需要高性能的應用程序。

需要確保數據的原子性和一致性。

業務邏輯相對簡單，不需要太多的代碼重用。

然而，在大多數情況下，將業務邏輯放在應用程序中可能是更好的選擇，因爲這樣可以提高代碼的可維護性和可重用性，並降低測試的難度。

工程師的設計能力區別在於是否全局性思考性能，可測試性，安全，可擴展性等質量特性。

《Domain Logic and SQL》
《Put business logic in the application, not the database》

今天先到這兒，希望對雲原生，技術領導力，企業管理，系統架構設計與評估，團隊管理, 項目管理, 產品管管，團隊建設有參考作用 , 您可能感興趣的文章:
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

如有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。該文章也同時發佈在我的獨立博客中-Petter Liu Blog。

應用系統-業務邏輯寫入在分層結構中Service層