關於暴露業務模型(Exposed Domain Model Pattern)1
關於暴露業務模型(Exposed Domain Model Pattern)
這個問題涉及到企業應用社群中許多流行了好多年的熱門詞:POJO,DTO(VO),FAÇADE。這個問題非常複雜,比貧血模型更易引起爭論;其中由方法論層面上的問題,也有技術層面的問題,在這裡也無法給出全面的分析,那就只能談幾點認識,可能帶有一些傾向性,其實這類問題本來就有一個價值選擇的問題。這些傾向和選擇也都是緣於實際的體會。
我首先注意到一點,Exposed Business Model Pattern說法的出現實際上跟Domain Driven 以及 Model Driven有直接的關係,實際上它們之間也的確有內在的聯絡,可以這樣說:Exposed Business Model Pattern使前者的驅動力量貫通所有的三個層。持久層集中反映模型的靜態結構,業務邏輯曾集中反映模型的動態行為,那末,表現很自然地應該直接地去渲染模型,從這個角度看問題,應該承認模型暴露的基本合理性。這是其一。另外一點是,歷史上DTO(VO)\FACADE模式在J2EE體系中的擴張,如果稍加留意就能看出,其根源很大程度上來自於某些技術的侷限性(其中一些侷限現在仍然存在),而隨著領域驅動、模型驅動等方法論的深入以及一些技術、平臺的發展,相當一些原因已經流失了。
從理論上說,在整體上,功能用例是模型的一部分,是模型作為一個有窮自動機時,在它全部的狀態空間中,對於系統的外部使用者有價值的一些狀態變化路徑的集合,表現層所表現的是模型的一部分,也是模型的一個子集;在區域性上,表現層的一個元素或者一部分元素所表現的也是一些完整的模型物件的一個剪裁;在各個方面都可以認為功能層、表現層是為模型開的一個視窗,透過它系統的外部使用者獲得了自己的價值。說得形而上一些,系統的功能集合是系統使用者的價值觀作用於模型的結果。模型更完備,功能則反映了使用者的價值取向。這幾點是封裝模型合理性的一個基本解釋,實際上Façade層的各個Service也基本上對應著功能用例,DTO本身則是模型物件的剪裁。也就是說在封裝模型中,系統地設計者為這個視窗安排了專門的一個層、專門的一套中間物件來形成這個視窗。
但是問題隨之而來:如果這個視窗足夠大以至於接近於完全暴露,這種安排必然就是多餘的,最起碼,過多的安排就是多餘的,所謂過多的問題應該這樣理解:這種安排是否應該導致一個獨立的層的存在以及幾乎與模型物件等量的DTO物件的存在。答案是否定的,根據如下:
模型並非是先於使用者的價值需求而存在的,而且正好相反,因此模型在整體規模上不會超越功能集合:在系統性、完整性上優於功能集合,在尺度上基本是功能集合的外包絡或者凸殼。也就是說,這個功能視窗必然使模型幾乎完全暴露;從這個意義上,Façade和DTO只不過是另一個冗餘模型而已
如前所述,因為功能角度和模型角度價值觀的差異,在兩者之間會出現一些轉換環節;但是這些環節並不足以構成一個幾乎與模型相等規模的冗餘模型的存在的理由。
對於轉換環節,理論上可以透過具體的技術層面的手段來解決,而不是方法論層面上的體系層面上的安排;實踐上,這些技術手段也越來越多。
最後一點,最起碼的,軟體開發哲學中普遍適用的思路:折中,將中間冗餘降低到最小。或者說,冗餘模型應該被抑制。
另外一個在方法論上需要充分關注的一個要點是,冗餘模型的存在會導致一些後果。模型驅動方法論的實質在於,在零散的、隨機的、短視的使用者需求和開發活動之間存在一個十分關鍵的中間概念模型,它更為理性,更為完備,它是對使用者需求的總結和提升,它被使用者需求所驅動,但又高於使用者需求,即面向使用者現實的需求,被這種需求所驅動,又面向使用者未來的可能的需求,因此它對系統的可擴充套件性有決定性影響,是軟體系統能夠良性發展、進化的內在的根本保證。冗餘模型的存在很大程度上弱化了核心模型的這個作用,開發者往往應一時之需,在冗餘模型層首先實現了一些功能,核心層則沒有相應的進化;由於冗餘模型的必然的不完備性,模型驅動思想在這個環節上被阻隔。一個系統的行為(或者功能)和系統的結構應該是正交的、橫切的關係,功能模組由結構元件協同工作完成,結構元件橫切許多功能模組;功能模組是對系統的垂直劃分,結構元件是對系統的橫向剖解。如上文所述,冗餘模型很大程度上與功能用例是對應的,其後果是,作為邏輯層的結構單元,它與功能模組之間是平行的關係。這是Service—DAO模式縱向分割系統的根源。
以上所述的各種情況實際上將冗餘模型推上尷尬境地:因為它直接面向功能用例,其結構必然與功能模組平行;如果這種與功能模組平行的結構單元承載了實質性邏輯,則違反了結構-功能正交的一般規律;另一方面,冗餘模型的存在又必然吸引開發和設計活動將大量的邏輯安排給它。如果它沒有實質邏輯,只是一層很薄的封裝,則根據上文的分析,它的存在的必要性就基本消失。所以,冗餘模型的存在是一個悖論。
這個問題涉及到企業應用社群中許多流行了好多年的熱門詞:POJO,DTO(VO),FAÇADE。這個問題非常複雜,比貧血模型更易引起爭論;其中由方法論層面上的問題,也有技術層面的問題,在這裡也無法給出全面的分析,那就只能談幾點認識,可能帶有一些傾向性,其實這類問題本來就有一個價值選擇的問題。這些傾向和選擇也都是緣於實際的體會。
我首先注意到一點,Exposed Business Model Pattern說法的出現實際上跟Domain Driven 以及 Model Driven有直接的關係,實際上它們之間也的確有內在的聯絡,可以這樣說:Exposed Business Model Pattern使前者的驅動力量貫通所有的三個層。持久層集中反映模型的靜態結構,業務邏輯曾集中反映模型的動態行為,那末,表現很自然地應該直接地去渲染模型,從這個角度看問題,應該承認模型暴露的基本合理性。這是其一。另外一點是,歷史上DTO(VO)\FACADE模式在J2EE體系中的擴張,如果稍加留意就能看出,其根源很大程度上來自於某些技術的侷限性(其中一些侷限現在仍然存在),而隨著領域驅動、模型驅動等方法論的深入以及一些技術、平臺的發展,相當一些原因已經流失了。
從理論上說,在整體上,功能用例是模型的一部分,是模型作為一個有窮自動機時,在它全部的狀態空間中,對於系統的外部使用者有價值的一些狀態變化路徑的集合,表現層所表現的是模型的一部分,也是模型的一個子集;在區域性上,表現層的一個元素或者一部分元素所表現的也是一些完整的模型物件的一個剪裁;在各個方面都可以認為功能層、表現層是為模型開的一個視窗,透過它系統的外部使用者獲得了自己的價值。說得形而上一些,系統的功能集合是系統使用者的價值觀作用於模型的結果。模型更完備,功能則反映了使用者的價值取向。這幾點是封裝模型合理性的一個基本解釋,實際上Façade層的各個Service也基本上對應著功能用例,DTO本身則是模型物件的剪裁。也就是說在封裝模型中,系統地設計者為這個視窗安排了專門的一個層、專門的一套中間物件來形成這個視窗。
但是問題隨之而來:如果這個視窗足夠大以至於接近於完全暴露,這種安排必然就是多餘的,最起碼,過多的安排就是多餘的,所謂過多的問題應該這樣理解:這種安排是否應該導致一個獨立的層的存在以及幾乎與模型物件等量的DTO物件的存在。答案是否定的,根據如下:
模型並非是先於使用者的價值需求而存在的,而且正好相反,因此模型在整體規模上不會超越功能集合:在系統性、完整性上優於功能集合,在尺度上基本是功能集合的外包絡或者凸殼。也就是說,這個功能視窗必然使模型幾乎完全暴露;從這個意義上,Façade和DTO只不過是另一個冗餘模型而已
如前所述,因為功能角度和模型角度價值觀的差異,在兩者之間會出現一些轉換環節;但是這些環節並不足以構成一個幾乎與模型相等規模的冗餘模型的存在的理由。
對於轉換環節,理論上可以透過具體的技術層面的手段來解決,而不是方法論層面上的體系層面上的安排;實踐上,這些技術手段也越來越多。
最後一點,最起碼的,軟體開發哲學中普遍適用的思路:折中,將中間冗餘降低到最小。或者說,冗餘模型應該被抑制。
另外一個在方法論上需要充分關注的一個要點是,冗餘模型的存在會導致一些後果。模型驅動方法論的實質在於,在零散的、隨機的、短視的使用者需求和開發活動之間存在一個十分關鍵的中間概念模型,它更為理性,更為完備,它是對使用者需求的總結和提升,它被使用者需求所驅動,但又高於使用者需求,即面向使用者現實的需求,被這種需求所驅動,又面向使用者未來的可能的需求,因此它對系統的可擴充套件性有決定性影響,是軟體系統能夠良性發展、進化的內在的根本保證。冗餘模型的存在很大程度上弱化了核心模型的這個作用,開發者往往應一時之需,在冗餘模型層首先實現了一些功能,核心層則沒有相應的進化;由於冗餘模型的必然的不完備性,模型驅動思想在這個環節上被阻隔。一個系統的行為(或者功能)和系統的結構應該是正交的、橫切的關係,功能模組由結構元件協同工作完成,結構元件橫切許多功能模組;功能模組是對系統的垂直劃分,結構元件是對系統的橫向剖解。如上文所述,冗餘模型很大程度上與功能用例是對應的,其後果是,作為邏輯層的結構單元,它與功能模組之間是平行的關係。這是Service—DAO模式縱向分割系統的根源。
以上所述的各種情況實際上將冗餘模型推上尷尬境地:因為它直接面向功能用例,其結構必然與功能模組平行;如果這種與功能模組平行的結構單元承載了實質性邏輯,則違反了結構-功能正交的一般規律;另一方面,冗餘模型的存在又必然吸引開發和設計活動將大量的邏輯安排給它。如果它沒有實質邏輯,只是一層很薄的封裝,則根據上文的分析,它的存在的必要性就基本消失。所以,冗餘模型的存在是一個悖論。
相關文章
- 關於暴露業務模型(Exposed Domain Model Pattern)2模型AI
- 對於domain model的包名的疑惑AI
- 一點疑惑:different from domain model and domain entityAI
- Grails + EJB Domain ModelsAI
- 業務領先模型(Business Leadership Model; BLM)模型
- (轉)關於 awk 的 pattern(模式)模式
- AxonFramework / Axon-trader Domain modelFrameworkAI
- Laravel Database——Eloquent Model 更新關聯模型LaravelDatabase模型
- 請教banq關於domain object的問題AIObject
- 撥開迷霧,找回自我:DDD 應對具體業務場景,Domain Model 到底如何設計?AI
- 關於DPM(Deformable Part Model)演算法中模型結構的解釋ORM演算法模型
- Django模型modelDjango模型
- 關於DPM(Deformable Part Model)演算法中模型視覺化的解釋ORM演算法模型視覺化
- 關於jdonframework-6.2.2中ModelUtil.isModel ()疑問Framework
- 關於貧血模型模型
- 模型Bean:Model Bean模型Bean
- 貧血模型 - DDD - The Domain Driven Design模型AI
- 關於ModelSaveAction等類的問題
- Markov Model 馬可夫模型 & Hidden Markov Model 隱馬可夫模型模型
- delphi基於資料模型(data-model)JSON序列模型JSON
- laravel Eloquent模型 關於模型關聯屬性獲取Laravel模型
- 關於 CSS 盒子模型CSS模型
- 關於RMA( 退貨)的業務流程
- 關於Select Model的兩篇譯文
- 請教:能介紹一下Domain Model(域建模)嗎?AI
- 貧血模型與充血模型比較 - DDD - The Domain Driven Design模型AI
- 關於業務元件相關架構的討論元件架構
- 關於盒模型相關的問題模型
- 關於FFMPEG的解碼模型模型
- 關於Actor模型的實現模型
- [Android] 關於 Model 層的幾點思考(一)Android
- 關於重寫 v-model 的一點感想
- 《推薦系統實踐》關於Latent Factor Model
- 12、flask-模型-modelsFlask模型
- [Shell] awk學習(1)-pattern{action}
- 關於模型關聯 獲取不到關聯資訊 求教模型
- 關於color modeling的一點疑惑
- YYModel 原始碼歷險記:關於ivar,method,property原始碼