靈活設(shè)計可以使我們隨著項目開發(fā)的進(jìn)行，感到速度越來越快，而不是越來越慢，甚至 停滯不前。靈活設(shè)計是對領(lǐng)域建模的補(bǔ)充，當(dāng)我們從領(lǐng)域中抓住那些隱隱約約的線索和概念原型后，就象準(zhǔn)備好原料；下面就是通過迭代將原料錘煉成一定具體的形狀，可以俗稱“打鐵”，那么打鐵打到什么形狀算可以了呢？ 也就是最終希望達(dá)到什么樣的設(shè)計呢？
有些軟件打著“靈活性”旗號，卻出現(xiàn)很多多余的抽象和間接層次，從而導(dǎo)致了復(fù)雜性，靈活性可能導(dǎo)致復(fù)雜性， 但是靈活性不是導(dǎo)致復(fù)雜性的必然原因，如何將靈活性的發(fā)展通往簡單，其中精湛技巧就需要學(xué)習(xí)和不斷實踐， 正確的理論指導(dǎo)是必不可少的，模型驅(qū)動設(shè)計(MDD)提供這樣一個科學(xué)的方法論。
在Eric Evans的“領(lǐng)域驅(qū)動設(shè)計”一書中專門探討了這樣提供靈活設(shè)計的模式和方法，下面簡要述說如下：
明顯意圖的接口
接口的名稱必須表達(dá)明顯意圖，而不是模棱兩可，接口雖然是抽象，但是也不能抽象到別人不知你所云， 如果其他開發(fā)人員必須查看接口的實現(xiàn)子類才能搞清楚你這個接口的意圖，那么你的接口抽象無疑是失敗的，
使用明顯意圖的接口可以將整個子領(lǐng)域切分成一個個單獨模塊，每個模塊使用帶有明顯意圖的接口封裝起來， 這種切割方式用來調(diào)整項目的焦點和對付大型系統(tǒng)的復(fù)雜性。
如果僅僅有大型系統(tǒng)開發(fā)經(jīng)驗，但是沒有大型系統(tǒng)的分割經(jīng)驗，更重要的是良好設(shè)計理論基礎(chǔ)，那些大型 系統(tǒng)開發(fā)經(jīng)驗也只是如過眼煙云，不會在你的程序生涯中占據(jù)多大的重要位置。
下面我們聚焦被劃分成單個模塊的內(nèi)部設(shè)計模式：
邊界影響
在軟件中，操作分為：命令和查詢，命令就是能夠使 系統(tǒng)狀態(tài)發(fā)生改變的操作，如增刪改等操作。這些操作都可能需要有副功能，如希望增刪改完成后還要返回一些結(jié)果，這些主要功能之外的副業(yè)，也稱為邊界影響(side effect)。一些傳統(tǒng)過程經(jīng)驗的程序員經(jīng)常喜歡搞“一機(jī)多用”，喜歡將很多功能揉合在一起。
大多數(shù)操作會調(diào)用其他操作，造成任意深度的嵌套，這樣形成一個樹形結(jié)構(gòu)的調(diào)用關(guān)系，這就容易使我們很難 預(yù)測調(diào)用一個操作會產(chǎn)生什么樣的結(jié)果，調(diào)用一個操作變得謹(jǐn)慎，甚至戰(zhàn)戰(zhàn)兢兢，雖然Ioc或DI container使 得這種嵌套關(guān)系的管理變得容易，但是不能保證每個操作本身的設(shè)計能降低復(fù)雜性，后者就是我們現(xiàn)在關(guān)注的。
為什么我們調(diào)用一個操作時會變得小心，因為這個操作設(shè)計時可能不執(zhí)行主要功能，還有其他副功能，這些 副功能可以認(rèn)為是一種多余副作用，解決辦法很簡單：設(shè)計這個操作時消滅副作用；如果不能消滅，就將其 分離顯式分離并單獨表達(dá)出來。
所以，我們設(shè)計增刪改命令和查詢功能時，盡可能分離它們到不同操作中實現(xiàn)，不要在增刪改命令執(zhí)行的同時 返回任何領(lǐng)域數(shù)據(jù)。
如果邊界影響不能通過設(shè)計避免，那么我們就直面它，在增刪改等命令執(zhí)行同時返回數(shù)據(jù)，當(dāng)這樣做的同時， 我們就使用斷言assertion來約束我們這樣的設(shè)計，通過斷言能夠易于使用單元測試Junit等工具測試。從而 保證你的命令簡單有規(guī)則。
總之還是那句有些哲學(xué)意義的話：對于邊界功能，首先要去除它，如果不能回避它，就承認(rèn)它，但是同時會約束它。
邊界影響主要的是Service接口怎么做的問題。在實際項目中，Model和Service是相互結(jié)合不斷重構(gòu)的。那么Model和Service粒度是如何界定的？
粒度界定
對象的粒度到底是多大？這沒有一個統(tǒng)一的規(guī)律，哪些屬性或行為屬于A對象，哪些屬于B對象，有時又需要將這些屬性和行為分離以便能夠靈活組合。我們一般很難確定類的粒度到底是怎樣規(guī)模表示達(dá)到設(shè)計目的？
首先，粒度不能太大，造成重復(fù)和冗余，很多概念混在一起；當(dāng)然粒度也不能太細(xì)，以至于太碎，不能完整表達(dá)一個領(lǐng)域概念，例如半個鈾原子就不再是鈾。
類需要盡量準(zhǔn)確表達(dá)領(lǐng)域概念，大多數(shù)領(lǐng)域中都包含某種邏輯上的一致性，而很多程序員有時只注意單純的設(shè)計原則，忽視領(lǐng)域邏輯，設(shè)計思考時需要兩條腿走路，實現(xiàn)平衡，比如Jdonwork的緩存設(shè)計主要應(yīng)對企業(yè)領(lǐng)域大量查詢都是在時間上相對集中的查詢（如本月度），因為領(lǐng)域中某種邏輯存在(時間上相對集中的查詢)，才使得我們決定采取某種設(shè)計方案，如果沒有這個前提，任何設(shè)計方案都是可行的，這也是我們通常討論的業(yè)務(wù)場景。
每個人對業(yè)務(wù)領(lǐng)域中很多概念都可能不一致，但不能否認(rèn)：領(lǐng)域中一定在某個地方存在一種旋律，我們的模型肯定能夠與領(lǐng)域某個部分發(fā)生共振，問題關(guān)鍵是：我們需要通過不斷發(fā)現(xiàn)的過程來尋找這種共振，這過程就依賴反復(fù)的重構(gòu)重整refactoring。
通過重構(gòu)，使我們的設(shè)計適應(yīng)我們重新理解了的領(lǐng)域概念和業(yè)務(wù)需求，概念輪廓(Conceptual Contour)就會浮現(xiàn)。
注意“概念輪廓”是指對領(lǐng)域中概念的主要輪廓，大概樣子，需要忽視不重要的細(xì)節(jié)，設(shè)計人員必須理解領(lǐng)域中概念在哪些地方會發(fā)生改變？哪些地方保持相對穩(wěn)定，然后使設(shè)計的模型盡量與領(lǐng)域中概念穩(wěn)定面結(jié)合起來，這樣，當(dāng)業(yè)務(wù)領(lǐng)域中概念發(fā)生變化時，我們的模型才會隨之一起翩翩起舞，發(fā)生共振，從而達(dá)到模型設(shè)計反應(yīng)領(lǐng)域本質(zhì)的目的。
所以，類的粒度是要能夠反應(yīng)領(lǐng)域的概念輪廓，將能夠反應(yīng)概念輪廓的那些重要元素聚合到當(dāng)前正在設(shè)計的類中，這也是設(shè)計中高聚合原則的體現(xiàn)。
高聚合、低關(guān)聯(lián)是兩個設(shè)計基本原則，上面我們談了如何做到高聚合，實際上，也是反映一種類或模塊的粒度設(shè)計規(guī)模。下面談?wù)劦完P(guān)聯(lián)：
消滅依賴
復(fù)雜的依賴關(guān)系無疑提高了系統(tǒng)的復(fù)雜性，加劇我們大腦負(fù)載，所以，我們的模型之間關(guān)系必須精練，減少依賴，最后保留下來的依賴代表了領(lǐng)域概念之間某種根本的關(guān)系。有的系統(tǒng)中，甚至是0關(guān)聯(lián)，從而得到一個個被完全孤立的單獨的類(standalone Class)，這才是方向（也有利于我們簡化配置Hibernate這些模型持久化框架，無需考慮一對多等關(guān)聯(lián)配置）。
每個依賴都是值得懷疑的，這是我們思考的前提，重構(gòu)時，一個個去消滅那些象蜘蛛網(wǎng)一樣密集的關(guān)系，斬斷它們，低關(guān)聯(lián)時減輕概念過載問題的基本方法，孤立類是低關(guān)聯(lián)達(dá)到極致的一種標(biāo)志。
減少依賴不是意味不考慮業(yè)務(wù)領(lǐng)域場景概念，武斷實現(xiàn)，依賴和之前描述的邊界影響一樣，有時確實不能消滅，那么我們就承認(rèn)它，但是會又有一套設(shè)計原則來約束它。
相關(guān):
領(lǐng)域模型驅(qū)動設(shè)計(DDD)之模型提煉
面向?qū)ο蠓治鰧嵺`過程是什么？
實戰(zhàn)DDD(Domain-Driven Design領(lǐng)域驅(qū)動設(shè)計)