問題
之前自己寫亂寫的時候，總是把業務邏輯寫在 controller 裡面。
也看到有人說，要把邏輯放在 dao 之上的 service 層。
在最近的乙個小專案中，發現邏輯稍微複雜一點兒，把業務邏輯放在 controller 裡面就不可維護了。
感覺又象是回到了以前過程式的程式設計，一點兒物件導向的味道都沒有了。
那麼，到底在哪些寫業務邏輯?
在model 層面，部署業務邏輯
在service 層面，部署應用邏輯
業務邏輯和具體的業務相關；應用邏輯和資料庫儲存相關。
要注意設計和 model，設計好類，還有方法。在這個層面，最考驗物件導向的設計功夫。
關於架構 框架 業務邏輯的理解
最近在回顧和總結上乙個五年的工作成長歷程，其中加入了個人對架構 框架 業務邏輯的理解，順便摘抄下來分享到部落格。由於個人認知有限，難免存在紕漏。1 架構 按照我的理解，架構有廣義和狹義的解釋。從廣義角度來說，它是人類進行社會化生產的組織形式，以及為保證組織形式能夠正常開展的方方面面。乙個典型的案例就...
架構設計 業務邏輯層簡述
業務邏輯層是專門處理軟體業務需求的一層，處於資料庫之上，服務層之下，完成一些列對domain object的crud，作為一組微服務提供給服務層來組織在暴露給表現層，如庫存檢查，用法合法性檢查，訂單建立。業務邏輯層包含領域物件模型，領域實體，業務規則，驗證規則，業務流程。1 領域物件模型為系統結構描...
業務模型 業務概念建模 系統模型 應用邏輯架構
從方法到思維 什麼是應用邏輯架構的正確姿勢？職責明確，某種粒度的模組 包括域 元件 系統 包 類 方法 上述模組之間的明確的關聯關係 若干約束和指導原則 軟體設計本身，模組，粒度，職責，復用，等等，在講解軟體設計的時候，使用的是這個架構圖，這個架構圖是通過系統模型和業務概念架構推導而來。所以系統模型...