領域驅動設計-軟體中的對象

軟體中的對象About DOMAIN-DRIVEN DESIGN

領域驅動設計是一種思維方式，目的在於處理具有複雜問題的軟體項目。在傳統的瀑布軟體開發模型中，經曆需求分析、設計、開發、測試、交付等階段，但是問題在於需求從業務方傳遞到Team Dev的時候並不是很順暢。儘管需求階段整理了複雜詳細的需求文檔，設計階段也產出了詳細設計文檔，但是開發人員由於很少參與了問題域的分析和建模，他們對設計文檔的理解往往是片面的，有時甚至會推翻設計文檔的模型創作一些臨時解決方案，而且往往這時都會有冠冕堂皇的理由---效能。許多設計文檔自書寫之日起就被束之高閣，我的一個同事L說我們的文檔修改日期永遠只是建立日期，因為設計文檔的更新遠遠跟不上代碼的更新，有時候並不是說邏輯變動多麼多麼大，只是更新設計文檔有時居然比更新代碼成本還要高！這種現象在我的項目中屢見不鮮，我越來越意識到設計和開發脫節的危險。

開發人員自身也有一些問題，人們很容易將經曆和技能集中在技術細節上，軟體的網路、資料庫等技術層面是技術人最愛討論的內容。這也跟環境有很大的關係，企業中、社區論壇中充斥著對選擇哪種編輯器、那種語言的爭論，我看到很多人以精通某種架構為榮，好想有了架構所有的問題都迎刃而解了。我花了三周的時間將LUA引擎做了封裝，可以無縫的在C++中調用LUA代碼，同時將C++類可以很輕鬆的註冊到LUA中，使用了C++的模板實現了tolua++、luabind的功能。但是這一切完成的時候，我自信的交付的時候，F同事安排我使用LUA實現任務系統，我想了又想、想了又想，突然發現我毫無頭緒，因為我對任務系統的邏輯沒有認知，縱然LUA效能多麼好、多麼小巧、文法多麼簡潔，但是在不理解任務系統的情景下我能保證開發出高新能的服務？縱然實現其準系統已經是不小的挑戰了，還要支援策劃人員動態添加、修改、刪除任務定義等額外功能。

我漸漸意識到，許多軟體的最主要的複雜性並不在技術上，而是在領域上、使用者的活動或業務。如果問題域的負責性沒有解決，再好的技術（LUA？LAMADA？ASYNC？MULTI_THREAD？）都是浮雲。我們每個人精力都是有限的，故此則失彼，如果對IDE的學習花費太多的時間那麼花在學習模式、建模上的時間必然會減少。認知超載，認知負荷理論中術語，問題解決和學習過程中各種認知活動均需消耗認知資源，若所有活動所需資源總量超過個體擁有的資源總量，就會引起資源的分派不足，從而影響個體學習或問題解決的效率，這種情況被稱為認知超載！

最近一直關注DOMAIN-DRIVEN
DESIGN的社區，受益匪淺。對軟體以及對象技術有了新的思考，這些思考還不太成熟，但是還是用文字記錄一下。

關於關聯

對象之間最基本的關係就是關聯，現實中對象往往是多對多的關聯，但是在代碼層面多對多關係是比較難維護、難理解的。如果對象A和對象B是一對一關聯性，那麼意味著A對象包含一個B對象的引用，B對象也包含一個A對象的引用，若A對應多個B對象，那麼A中就會包含一個B對象的集合（vector?set?map?hash_map?），A對象還會附加一些遍曆B的方法、尋找、添加的方法等。針對多隊奪得關係的指導原則是添加約束盡量使其變成一對一的關係。比如公司-員工的關係可能是多對多的關係，但是由於在某一時間段某人只能在一個公司就職，這樣添加period的約束，變成一對一的關係（一個公司在某個時間只有一個叫XX的員工）。DOMAIN-DERIVEN DESIGN中這樣規定：

l  規定對象的遍曆只有一個遍曆方向

l  添加限定條件，減少多重關聯

l  消除不必要的關聯

Entity

一些對象是由只有他們的屬性定義的，他們屬性在時間跨度上往往會發生變化，但是總有些特性是不變的、是可以唯一標識這個對象的。這樣的對象稱之為Entity，即實體物件。例如人這個對象是實體，他的名字可以唯一標識他嗎？答案是不能，他可能叫小明，同學可能給他起外號叫超級明，工作中可能有英文名Kevin，QQ帳號可能叫大灰狼，名字只是人的屬性，屬性在時間、空間跨度上是可以變化的，但是他的社會安全號碼碼是唯一註冊的，可以唯一標識這個小明這個人。當處理Entity時標識的選擇至關重要，因為Entity往往涉及到序列化儲存等情況，唯一標識往往影響其在序列化時的方案。

Value Object

Value Object即值對象。其只關心對象的屬性，在值對象生命週期內，一般屬性是不允許變化的，如果要變化，也是完全的更換value object整體而不是修改value object 部分屬性。比如地址address對象包含省、市、區、街道等屬性。Customer對象擁有一個address對象，該對象大部分情況是不需要修改的，即使Customer搬家了，address更換了，只需要重新建立一個address對象將老的替換掉即可。使用value object 可以對系統帶來非常大的最佳化。比如在任務系統中，每個任務都一段標題文字description，該對象完全屬於value object，每個task對象擁有一個description屬性，這裡完全可以使用引用而不是拷貝，由於我們限定了description不允許修改，他甚至是安全執行緒的。但系統中有成百萬的task對象時，記憶體最佳化就彰顯無遺了。實際上這種建模完全符合現實中的關係，從建模層面做到了最佳化，設計和開發銜接緊密，完全沒有脫節。

Service

         有時候對象不是一個事物，而是一系列的特殊動作。它用來協調各個對象之間的關係，一般以一個活動命名，一般它的名字會是個動詞。Service應該是無狀態的。在我們的任務系統中，有一個service叫做task_generator，他的職責是為user產生正確的新任務。他根據參數user的context為其產生任務，舉個例子，若user首次進入系統，那麼需要給其初始化一些基本任務比如說產生3個系列的強制任務。若此user是剛剛完成了一個任務，task_generator只需為其產生這個任務的後續任務即可。Task_generator只是包含一系列的動作而已，他操縱任務定義倉庫、task對象、user context資料等。Task_generator是無狀態的，所以多線程放完它，多user並發放完都不是問題，唯一的競爭在於任務倉庫是全域的，實現時使用了讀寫鎖。Task_generator，說白了，我們只是把一系列操縱封裝成了對象。

Module

我們經常提到module，使用module的優點是什麼。從第一天我們接觸編程老師就告訴我們軟體編程要分而治之。Module根本思想仍然是這個。Module的原則老生常談了，高內聚，低耦合。DOMAIN_DERIVEN DESIGN 中提到Module提供了兩種模型的認知方法：

l  在Module內部可以查看內部細節，而不需關係外部因素，因為Module是高內聚的

l  從module外部可以查看各個module之間的關係，而不需要考慮module的實現細節

DOMAIN_DERIVEN
DESIGN也強調，module的重構比對象的重構影響大的多，所以對module的重構要謹慎，而且module應該是中度粒度的，細粒度的module往往不合適，最好保證操作和資料的維護對象在同一個module中。

         在我們的任務系統中，整合了成就系統，二者是兩個獨立的module，唯一的聯絡只是使用者的行為基數（打怪等）會累加到相應的任務和成就上。DB的分庫分表也是一個獨立的module，邏輯層維護一個task_service將邏輯層的對象和Mysql中的資料實現映射。

Question

         DOMAIN-DERIVEN
DESIGN中有很多指導的建模模式，由於並不是很多都在項目中經曆過，很多並不是參的很透徹，目前的最大疑問是在建模階段，對於對象的抽象有什麼知道原則，尤其是當邏輯紛繁蕪雜毫無頭緒之時，那裡是比較好的Begin？

         一直以來，我都認為軟體和建築像極了，但是軟體比建築還要負責,因為軟體是無形的。我的一個一直糾結的問題是為什麼軟體這麼複雜！！

         DOMAIN-DERIVEN
DESIGN應該是個好的方向。引用老子的一句話：吾生也有涯，而知也無涯！

       後半句更有哲理：以有涯隨無涯，殆已。