Patterns for Organizing Domain Logic
What is a Design Pattern?
Design Pattern 通常需要具備幾個描述要件 Context, Problem, Solution。
Context
解釋目前遇到的問題,所以需要提出一個 pattern
Problem
描述遇到的問題,所以需要權衡的難點 (Forces),這個難點通常會是有互斥的狀況。
Solution
提出的方案,需要平衡難點,通常會需要提出兩個面向
靜態 Relationship
Run-time behaviour
Domian Logic Problem Context
Domain Logic 在維護上管理上,需要精準的處理 Business model 需要兼顧軟體的維護性、可理解性、效能以及可測試性。當隨著軟體迭代,維護性、可理解性、效能以及可測試性都會隨著時間越來越複雜。
Problem
要如何保持低開發成本
隨著時間產品生命週期越久,所需要開發成本越高
指的是維護性、可理解性、效能以及可測試性
開發時間: 測試時間,開發時間,理解程式碼
Solution
從[1] 文獻中,主要有三個 pattern 使用 Transaction Script, Table Moudle, Domain Model,隨著產品的生命週期,可以採用以順序為: Transaction Script -> Table Moudle -> Domain Model 。
Transaction Script
Def: Organizes business logic by procedures where each procedure handles a single request from the presentation
Transaction Scripts 不會再細分結構,像是 retrive data, handle request ... 。換句話說,將所有的邏輯封裝在 Object
中。
Static Structure
Dynamic Structure
Domain Model
Def: An object model of the domain that incorporates both behavior and data
在 Domain model 中,會明顯區分 Entity Object 與 Value Object。
Entity Object: 可直接對應商業邏輯的 component 並可直接取用 data,具有 identity 的特性 (唯一性)。
Value Object: 是一種裝飾 Entity Object 的一種結構。具備 Comparable 的特性。
在 Domain Model 需要盡可能對應需求的操作
Dynamic Structure
Table Moudle
def: A single instance that handles the business logic for all rows in a database table or view.
這一個介於 Domain Model 與 Transaction Script 的一種 Pattern。與 Domain Model 最大的區別在於 Object 沒有 ID 的概念,且沒有特別區別 Object 定義。
Static Structure
Dynamic structure
Conclusion
Transaction Scripts
在量體小的feature 是容易理解的
學習難度低
擴充性很差,當要持續維護的時候難度很高,且會有很多重複的程式碼。
一次性的 scripts
Domain Model
貼近 Business Logic
具備好的擴充性
相對於三個 patterns 中最複雜的
學習曲線難度高
長期大型專案
Table Module
具備好的擴充性
學習難度低
複雜度介於中間
Object 無法完全貼近真實情境
中長期大型專案
Reference
[1] Fowler, Martin. Patterns of enterprise application architecture. Addison-Wesley, 2012.
Last updated
Was this helpful?