I'm CaLendarW Blog

之前買果本 Domain-Driven Design 都睇到第 15 章, 基本既理念大致上有:

Factory
Repository
Specification
Domain Model with Aggregation

而宜家寫既 Code 大部份都會跟呢個方向做, 雖然有時都無寫 Factory 黎生產 Object, 但自己就將 Repository Inherent DAO, 咁加埋 Spring.net 既 NHibernate Template 就可以更快地寫好一個 Program, 而 Validation 呢部份就用 Specification 黎做, 配合埋 Shared Kernel 就可以支援唔同既 Bounded Context.

呢兩年寫 code 都會用 Data Access Object(DAO) 黎做 Data Layer 果部份, 因為可以夾返 object-oriented design 同 object-relational mapping, 增加返個 adaptability, 令到個 program 可以由 System.Data 轉去 NHibernate, 或者唔同既 Database Connection 既 Implementation (OleDb, ODBC 等, 雖然我大部份時間都係用 System.Data 入面既 Interface, e.g. IDbConnection, IDbTransaction).

用左 DAO 之後, 大部份既 SQL 都交由 DAO 負責, 除左 DAO 之外, 其他地方應該唔會出現 SQL, 我覺得咁樣會方便管理, 同埋係更改!! 而實際 Program 上面, 基本上係拎個 object 舞來舞去, 無乜咁大特別, 舞完一輪就用 DAO Update 返落 Db, 方便易用!!~

Smart UI 呢個 term 係我由 domain-driven design 本書度見到的, 係一個 anti-pattern, 指一個介面做晒所有 business logic, 佢既好處就係當個 program 係好細好細, 你搞咁多 design 其實係好浪費時間的, 所以係好適合一 d 細既 program, 例如功課上面用的.

不過, 當你 apply 左 smart ui 之後, 其實亦限制左個 software 既可擴展性, 因為所有既 business logic 都係晒個介面度, 如果你寫既 software 愈來愈大, 而 business logic 只可以不段咁 copy and paste, 就會變得複雜同難以管理, 當有 logic 要轉, 就要轉晒所有版面引用過既 code, 呢個亦都係之前我個 post 所講: “爛於抄, 精於用” 既道理, 亦正正就係點解要有 software design 同 software architecture 既原因!!

而我自己, 因為係一個太過 OO 既人, 凡事都 object-base, 所以我都會盡量唔比 smart ui 出自我手, 當然工作需要既我就要用, 但我有得選擇既話我一定會行 object-base!!!

呢排係 Code Project 度發現的, 而作者就不斷增加緊 content~~

• Software Architecture Interview Questions Part 1 ( Design Pattern )
• Software Architecture Interview Questions Part 2 ( Design pattern )
• Software Architecture Interview Questions Part 3 ( Design Pattern )
• Software Architecture Interview Questions Part 4 ( Design Pattern )
• UML Interview Questions Part 1
• UML Interview Questions Part 2
• View Video of Design Patterns
• SOA Interview questions Part 1 Recent Added

經過一個月讀過既幾本有關 Domain Driven Design 既書, 睇落使用性不大. 原因有以下幾點:

1. Highly Involve Client. 呢方面對 External Project 或 Internal Project 既使用性都不大. External 方面, 公司未必希望 Client 一齊 Design, 因為大部份既公司都會 Technology Focus, 所以 Client 比既 Idea 對未完全接受 DDD 既公司黎講未必接受到. Internal 方面, 高層雖然應該會有好既 Domain Knowledge, 以及比較容易做到 Involvement, 但係在於高層既角度又未必抽到咁多時間黎陪你做 Domain Design.
2. Use of infrastructure. 對於香港大部份 SME 黎講, 未必有良好既 infrastructure, 雖然現今有大量良好既 Open Source Project, 但未必適用於公司既原有 framework 同 culture, 而且就算 define 到一個好既 infrastructure, 都未必得到傳統既 Developer 接受.
3. Test Driven. 香港未必有咁多既 SME 公司會 Apply Test Driven, 因為係香港既社會, 好多 Outsource 既 Project 都會係短時間內完成, 所以係咁既環境下未必 Apply 到 Test Driven.

因此, 要將 Domain Driven Design 引入到香港既公司會比較難, 所以對我黎講都係 apply 一部份就算.