|
|
好久沒有寫文章了，最近比較忙，另一方面也是感覺自己在這方面沒什么實質性的突破。但是今天終于感覺自己小有所成，有些可以值得和大家分享的東西，并且完成了兩個可以表達自己想法的Demo。因此，趁現在有點時間，是寫文章和大家分享的時候了。
首先給出這兩個Demo的源代碼的壓縮包的下載地址，因為之前有博友說他沒有裝VS2010而沒辦法運行Demo，所以這次我分別用VS2008和VS2010實現了兩個版本。
http://files.cnblogs.com/NETfocus/DCIBasedDDD.rar
下面先分享一下我最近研究的一些知識及我對這些知識的自我感悟，然后再結合Demo中的示例講解如何將這些感悟應用到實際。
一、理論知識：
我最近一直在學習下面這些東西：
- 面向對象分析與設計，即Object Oriented Analysis and Design（OOA/D）
- 領域驅動設計，即Domain Driven Design（DDD）
- 四色原型：MI原型、Role原型、PPT原型、Description原型
- DCI架構：Data Context Interaction
- CQRS架構： 命令查詢職責分離原則，即Command Query Responsibility Segregation
通過學習以上這些知識，讓我對面向對象的分析、設計、實現有了一些新的認識。
1. 碰到一個業務系統，我們該如何分析業務，分析需求，并最后得到一個只包含業務概念的模型？答案是通過四色原型進行業務建模。四色原型的中心思想是：一個什么什么樣的人或組織或物品或地點以某種角色在某個時刻或某段時間內參與某個活動。 其中“什么什么樣的”就是DESC，“人或組織或物品或地點”就是PPT，“角色”就是Role，而”某個時刻或某段時間內的某個活動"就是MI。更具體的說明請參看我之前整理的一篇文章：四色原型的學習心得分享
2. 業務模型建好了，該如何通過面向對象的分析與設計方法來進行對象建模呢？ DDD和DCI思想可以幫助我們。首先，DDD能夠指導我們建立一個靜態的領域模型，該領域模型能夠清楚的告訴我們建立出來的對象“是什么”，但是DDD卻不能很自然的解決“做什么”的問題。大家都知道DDD在對象設計的部分實際上是一種充血模型的方式，它強調對象不僅有屬性還會有行為，如果行為是跨多個領域對象的，則在DDD中用領域服務解決。但是DDD卻沒有完整的考慮對象與對象之間的交互如何完成，雖然它通過領域服務的方式協調多個對象之間進行交互或者在應用層協調多個對象進行交互。但是在DDD中，對象往往會擁有很多不該擁有的屬性或行為。在我學習了DCI架構之后，我認識到了DDD的很多不足。
以下是DCI的核心思想：
- 對象扮演某個角色進入場景，然后在場景中進行交互，場景的參與者就是對象所扮演的角色；
- 一個對象可以扮演多個角色，一個角色也可以被多個對象扮演；
- 對象的屬性和行為分為：A. 核心屬性和行為，這些屬性或行為是不依賴于任何場景的；B. 場景屬性和行為，對象通過扮演某個角色進入某個特定場景時擁有的屬性或行為，一旦對象離開了這個場景，不再扮演了這個角色后，這些場景屬性或行為也就不再屬于該對象了；比如人有核心的屬性和行為：身高、體重、吃飯、睡覺，然后當人扮演教師的角色在教室里上課時，他則具有上課的行為，一旦回到家里，就又變成了一個普通的人；比如一個物品，在生產時叫產品，在銷售時叫商品，壞了的時候叫廢品，它在不同階段扮演不同的角色所具有的屬性是不一樣的；
- 場景的生命周期，場景是一個時間與空間的結合，可以理解為某個活動；一旦活動結束，則場景也就消失；
- DCI中的D可以理解為DDD中的領域模型；場景中交互的是角色，而不是領域實體。場景屬于DSL的思考層面，更接近于需求和用例。而領域也是偉大的出現，但是不能為了領域而領域，為什么呢？因為場景是大哥，用例是大哥。領域的存在是為了控制固定概念的部分，這樣在某種成度上控制了一定的復雜性和提高了可控性，而DCI則解決了可變性和需求的問題。從某種意義上來說，“領域層（在DCI中可能不會太凸顯領域層，不如OLD, DDD那么凸顯）” 是為了DCI架構服務的。
- 角色是人類的主觀意識，用于對象分析和設計階段，但是在運行階段，角色和對象實體是一體的，軟件運行過程中只有對象，只是這些對象在參與某個活動時扮演了某個角色而已。
3. 領域驅動設計中對象設計部分的一些要點：
- DDD的在對象設計方面的最大貢獻之處在于其實體、值對象，以及聚合邊界的三個部分，通過這三個概念，我們可以將對象的靜態結構設計好。
it知識庫：分享一些如何分析和設計具有動態行為的領域模型的經驗，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
