為了感謝flyzb的思想給我的幫助, 我特定整理了一些他的大部分我覺得重要的思想. 分享給大家.

tangxuehua發表於2011-01-26
以下知識是關於領域驅動設計（DDD）的, 大部分摘自flyzb的思想,雖然在很多人看來並不贊同, 但我個人認為對我啟發很大. 有興趣的可以看一下.
我一直覺得不要盲目相信權威，比如不能一談起領域驅動設計，就一定認為國外的那個Eric Evans寫的那本書中的一些概念就一定是正確的，認為領域驅動設計就一定是聚合，聚合根，實體，值物件等概念。我們要有自己的思想，要有自己判斷真正的領域模型該是什麼樣子的勇氣和追求。
1. "領域驅動設計" = “問題域模型驅動領域建模” + “領域建模驅動軟體實現”

2. 問題域建模的過程就是業務領域分析的過程，對於企業而言就是業務架構的分析和建立過程，這裡不包含任何OO的設計成分，主要從組織、流程和業務能力三個維度來分析業務。

3. 記住很多模式沒有什麼用處，帶著問題在模式中尋找答案才是正確的使用方式，讓那種解決方案的思想融入到你的模型當中，然後徹底地忘掉那些所謂的模式名詞。

4. 好的領域建模應該具有柔性，能夠伴隨著使用者一起成長。

5. 這讓我意識到業務建模應該回歸自然：一談起來建模技術，就離不開國外提出的OO、EDA之類的東西，其實我們的老祖宗早就有了“摸脈”的說法，現在的SOA、ESB之類的東西是不是就像打造一個企業的“神經脈絡”，而“OO”是不是就像“神經元”，它們之間的通訊就是靠生物電脈衝，這就是訊息驅動。

6. 《領域驅動設計》一書中只是強調了業務的水平分割，然而在大專案裡還有垂直分割，注意垂直分割不完全等同於包的劃分。目前有一種非常錯誤的做法，就是一上來就開始物件建模，然後再進行歸類劃分模組；正確的做法應該是前期以確認領域邊界功能為主，後期以確認領域內的物件模型為主。關於領域的切分，《領域驅動設計》沒有過多談及，其實方法就是不斷對企業業務知識的學習和分析。當你對一個業務認識不清的時候，最好的辦法就是不同企業環境下去分析這個業務，那這個業務的所有發展變化就清楚了，這就像那些生物學家總是喜歡透過長期的野外考查來學習知識。這個工作做好了，專案就成功了50%。

7. 領域的邊界就是服務，也是對外提供服務的唯一入口。領域服務和領域物件模型是一個業務領域的2個不同側面。領域服務強調是從外向內看，反映了“外部對業務領域的使用功能”；領域物件模型強調業務領域就像一個獨立的具有一定自主能力的生命體，反映了“業務領域的內部執行機制”。領域物件模型的功能是不能對外暴露的，不然會造成外部對領域物件的耦合。

8. 不要一說“面向關係設計”就是錯的。因為使用者的角度看，業務本來就是面向關係和過程的，這非常自然；而從設計看，業務是不同主體在相互作用。這就是為什麼越靠近使用者的地方面向關係和過程的設計味道越濃的原因了。

9. “類和職責”的叫法讓我總感覺比較僵化，像是沒有生命的死細胞一樣，覺得這是一種西醫模式。我更崇尚一種中醫模式，強調建模是動態的、基於場景互動的，應該用更自然的還原業務本來面目的眼光去審視建模過程，也就是說“有機的業務建模”實際上就是“技術建模”的問題域建模，而“技術建模”只是“業務建模”的技術落地而已。

10. 關於建模工具，像“用例圖，流程圖，狀態圖之類”的並不是我理想的建模工具，雖然他們確實能表達一些東西。我理想的業務建模工具應該是能從角色（組織或者人）、流程、業務能力三個維度立體地、動態地分析描述業務模型，希望可以是一個動態的3D檢視和流圖，並可以按不同的維度分析展開。

相關文章