閒談軟體設計:Model Model Model

更新於 發佈於 閱讀時間約 5 分鐘


可能是過去求學時,學的是《Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development》和《Object-Oriented Modeling and Design with UML, 2nd》書中描述的方式做物件分析與設計,從 use case 描述中抓出名詞成為 domain model,從動詞找出類別的行為和物件間的關聯,用 GRASP 原則將責任分配到合適的類別身上,但這個 domain model 離實際的 implementation model 還有段距離,畢竟還要跟使用的框架打交道。


就業後,對於 Model 這字眼總是特別小心,有趣的是,Model 其實沒什麼嚴格的定義,所以每個人對 Model 的解讀也不盡相同,有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響),有人覺得工作流程 (workflow) 是 Model 的一部份,我個人也有自己的想法,而且隨專案的規模和特性,也不是總是一樣的。

若看 Wikipedia 對 Multitier architecture 的描述,會發現常見的架構分成四層,每一層的責任似乎明確卻又有一點模糊,而我自己的見解是:

  • Presentation layer — 若是使用 server-rendering 為主要技術的框架中,這一層主要是將 application layer 的結果轉換成 HTML;若是在桌面應用程式或是 client-rendering 中,這一層主要就是 UI 相關的邏輯 (跳出對話框、切換視窗、更新視窗中的元件)。
  • Application layer — 如 Wikipedia 的描述,我亦是把這一層當作 GRASP 的 system event controller (此 controller 不等同 MVC 的 controller),並處理完成一個 use case 中非 domain (business) logic 的其他部分,例如:發送信件 (通知)、關係注入 (dependency injection)、infrastructure 或外部系統的調用、request 資料格式的檢查等。
  • Business layer — 基本上這一層只處理 domain objects 間的 relationship 以及確保最終狀態是符合 business rules,例如:在一個論文審查系統中,不能將一篇直接從 wait for review 移到 accepted 或 rejected (至少要經過審查)。
  • Data access layer — 這一層除了處理資料怎麼儲存 (persistence) 外,也包含如何從網路存取外部的資料。而在 persistence 這件事上,個人比較偏好 Repository pattern。

雖然這樣看起來,四層很明確啊!但實際在寫程式時,還是會有一些模糊的空間,有時候還是要思考這一段程式應該放在哪一層,特別是 application layer 和 business layer 之間更是如此;因此,也可以說,每個人對於 Model 到底是包含 application layer 還是 business layer 的哪些部分看法不太一致,對我來說,二者都是 Model,但若分成四層,二者不會是同一個物件。

程式的結構 (以目錄或其他方式呈現) 上,有時也不容易看出結構與分層的對應關係。有時候,強制分成四層也會讓程式架構變複雜,所以我在桌面應用程式或 Mobile App 中,我可能選擇讓 application layer 與 business layer 合併,簡化成三層,或是讓 application layer 非常的薄。

在 Web 應用中,原則上還是分成四層,但個人偏好 client-rendering,因此 presentation layer 通常在 client,不過,為了方便測試,有時候 Web server 端還是會有負責提供 presentation model 的 presentation layer。例如用 Spring 框架來撰寫,application layer 的程式有時會散在 filter (身份認證或權限控管)、interceptor (稽核) 和 request controller (直接當成 system event controller) 中,但原則上 request controller 的程式大多很短,主要邏輯還是在 business layer 裡。

或許,事情不用這麼複雜,在設計每個 class 時或是想將功能加到一個 class 時,用 single responsibility 的原則來思考,適合放在這個 class 嗎?若不合適,應該放在哪裡呢?這時候參考軟體的架構思考應該放在哪一層。在層與層之間的 dependency 該如何管理或注入時,多想想 interface segregation 原則,不要直接依賴實作,甚至可以想一下 dependency inversion 原則,降低上層程式與下層程式的依賴,盡可能讓每一層都能維持獨立,此時,要進行測試就容易多了。

總結來說,對 Model 的解讀可以各自不同,沒什麼標準答案,但不論用什麼方式解讀,只要能讓程式易讀好維護,就是好的設計。

留言
avatar-img
留言分享你的想法!
avatar-img
Spirit的沙龍
54會員
107內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
Spirit的沙龍的其他內容
2024/03/23
這篇文章探討了在軟體開發中的技術債可能來自哪些原因,以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇,提供了對於技術債的思考與建議,針對開發人員在需要做出無奈的技術決策時,提供了一些建議。此外,還提供了一些在做出技術決策時的方法,如保留抽象層和避免vendor lock-in。
Thumbnail
2024/03/23
這篇文章探討了在軟體開發中的技術債可能來自哪些原因,以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇,提供了對於技術債的思考與建議,針對開發人員在需要做出無奈的技術決策時,提供了一些建議。此外,還提供了一些在做出技術決策時的方法,如保留抽象層和避免vendor lock-in。
Thumbnail
2024/03/09
今天來聊個最近很夯的主題 DDD,但不是 DDD 的本尊 Domain Driven Design,而是無所不在的 Database Driven Design,Database Driven Design 不是不好,只是你的模型容易變成貧血模型,邏輯都集中在 service 層等等。
Thumbnail
2024/03/09
今天來聊個最近很夯的主題 DDD,但不是 DDD 的本尊 Domain Driven Design,而是無所不在的 Database Driven Design,Database Driven Design 不是不好,只是你的模型容易變成貧血模型,邏輯都集中在 service 層等等。
Thumbnail
2024/02/24
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別,當時寫了首部曲《閒談軟體設計:API Naming Style》,接著是《閒談軟體設計:內部函式庫》,但始終沒談到 library 和 framework 的差別,主要是沒有好的例子,這次這例子還蠻不錯的。
Thumbnail
2024/02/24
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別,當時寫了首部曲《閒談軟體設計:API Naming Style》,接著是《閒談軟體設計:內部函式庫》,但始終沒談到 library 和 framework 的差別,主要是沒有好的例子,這次這例子還蠻不錯的。
Thumbnail
看更多
你可能也想看
Thumbnail
孩子寫功課時瞇眼?小心近視!這款喜光全光譜TIONE⁺光健康智慧檯燈,獲眼科院長推薦,網路好評不斷!全光譜LED、180cm大照明範圍、5段亮度及色溫調整、350度萬向旋轉,讓孩子學習更舒適、保護眼睛!
Thumbnail
孩子寫功課時瞇眼?小心近視!這款喜光全光譜TIONE⁺光健康智慧檯燈,獲眼科院長推薦,網路好評不斷!全光譜LED、180cm大照明範圍、5段亮度及色溫調整、350度萬向旋轉,讓孩子學習更舒適、保護眼睛!
Thumbnail
創作者營運專員/經理(Operations Specialist/Manager)將負責對平台成長及收入至關重要的 Partnership 夥伴創作者開發及營運。你將發揮對知識與內容變現、影響力變現的精準判斷力,找到你心中的潛力新星或有聲量的中大型創作者加入 vocus。
Thumbnail
創作者營運專員/經理(Operations Specialist/Manager)將負責對平台成長及收入至關重要的 Partnership 夥伴創作者開發及營運。你將發揮對知識與內容變現、影響力變現的精準判斷力,找到你心中的潛力新星或有聲量的中大型創作者加入 vocus。
Thumbnail
樣板模式的定義極為簡單,卻是大型系統程式、WEB/APP應用框架的設計核心,完美展現設計模式的價值: 簡單、高效、強大。
Thumbnail
樣板模式的定義極為簡單,卻是大型系統程式、WEB/APP應用框架的設計核心,完美展現設計模式的價值: 簡單、高效、強大。
Thumbnail
本書大多數的內容都以 OO 的概念出發,詳列了許多設計的臭味道,也有大量的例子。個人雖然不會這樣寫程式,但仍是覺得受益良多,至少在 code review 時能更清楚知道該怎麼描述問題。不過,即便不是用 OO 的概念,有些章節還是可以帶來一些想法,用 OO 概念寫程式的人更不該錯過這本好書。
Thumbnail
本書大多數的內容都以 OO 的概念出發,詳列了許多設計的臭味道,也有大量的例子。個人雖然不會這樣寫程式,但仍是覺得受益良多,至少在 code review 時能更清楚知道該怎麼描述問題。不過,即便不是用 OO 的概念,有些章節還是可以帶來一些想法,用 OO 概念寫程式的人更不該錯過這本好書。
Thumbnail
實際就業後,會發現收集與分析需求,通常都不是工程師在做,會有另一群人,以非工程的角度收集及分析需求,然後在開發過程中蹦出不同的火花,於是很好奇另一群人的想法是什麼?我不敢說這本書能完全代表另一群人的想法,但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
Thumbnail
實際就業後,會發現收集與分析需求,通常都不是工程師在做,會有另一群人,以非工程的角度收集及分析需求,然後在開發過程中蹦出不同的火花,於是很好奇另一群人的想法是什麼?我不敢說這本書能完全代表另一群人的想法,但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
Thumbnail
觀察者模式透過主題訂閱/訊息通知的機制,極度增強系統的可擴展性、靈活性以及降低組件間的耦合度。概念直觀簡單,是非常實用的設計模式。
Thumbnail
觀察者模式透過主題訂閱/訊息通知的機制,極度增強系統的可擴展性、靈活性以及降低組件間的耦合度。概念直觀簡單,是非常實用的設計模式。
Thumbnail
軟體系統的發展歷程大多相似,首重解決基本需求、提供操作介面,進而提升安全性、擴充功能、優化操作。
Thumbnail
軟體系統的發展歷程大多相似,首重解決基本需求、提供操作介面,進而提升安全性、擴充功能、優化操作。
Thumbnail
代理模式通過封裝原始對象來實現對該對象的控制和管理,同時不改變原始對象的行為或客戶端與該對象互動的方式,以此介入或增強對該對象的訪問和操作。
Thumbnail
代理模式通過封裝原始對象來實現對該對象的控制和管理,同時不改變原始對象的行為或客戶端與該對象互動的方式,以此介入或增強對該對象的訪問和操作。
Thumbnail
資料的統合 在程式設計中,其他人通常關心是否注意到執行的細節。作為程式設計師,主要應該關心的是程式的表現,但往往忽略了很多細節,這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合,也就是資料是否被正規化。 不同類型的資料在系統中呈現一致 正規化可能對一些人來說聽起來很抽象,有些人
Thumbnail
資料的統合 在程式設計中,其他人通常關心是否注意到執行的細節。作為程式設計師,主要應該關心的是程式的表現,但往往忽略了很多細節,這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合,也就是資料是否被正規化。 不同類型的資料在系統中呈現一致 正規化可能對一些人來說聽起來很抽象,有些人
Thumbnail
有趣的是,Model 其實沒什麼嚴格的定義,所以每個人對 Model 的解讀也不盡相同,有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響),有人覺得工作流程 (workflow) 是 Model 的一部份,我個人也有自己的想法,而且隨專案的規模和特性,也不是總是一樣的。
Thumbnail
有趣的是,Model 其實沒什麼嚴格的定義,所以每個人對 Model 的解讀也不盡相同,有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響),有人覺得工作流程 (workflow) 是 Model 的一部份,我個人也有自己的想法,而且隨專案的規模和特性,也不是總是一樣的。
Thumbnail
替產業做設計 有人要我談程式設計,那我就稍微談一下。我從事的大都是產業的工作,所以我們也從如何替產業做設計來談起。基本上,每個產業都會有自己的作業流程,大同小異。但是基礎來做都是一樣的,都會有客戶、物料、產品、供應商、員工等資料。不同的是,由於企業型態的不同,他們每個人有不同的作業流程。這個作業流
Thumbnail
替產業做設計 有人要我談程式設計,那我就稍微談一下。我從事的大都是產業的工作,所以我們也從如何替產業做設計來談起。基本上,每個產業都會有自己的作業流程,大同小異。但是基礎來做都是一樣的,都會有客戶、物料、產品、供應商、員工等資料。不同的是,由於企業型態的不同,他們每個人有不同的作業流程。這個作業流
Thumbnail
提到後端工程師,似乎就只是開發 API,但一個複雜的系統其實不太可能只透過 API 就能完成,例如一個簡單的功能,註冊會員,其實是由好幾個不同類型的工作互相配合,您才能收到開通信,才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
Thumbnail
提到後端工程師,似乎就只是開發 API,但一個複雜的系統其實不太可能只透過 API 就能完成,例如一個簡單的功能,註冊會員,其實是由好幾個不同類型的工作互相配合,您才能收到開通信,才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News