更多文章請參見：我的blog

1. 問題域定義

這個問題往大的說是業(yè)務(wù)治理問題，往小了說是代碼分拆。
我的建議是自頂向下的思考，自頂向下的思考方式一方面全局的看一個問題，能給出一個問題最優(yōu)解，另一方面因為只有這樣才有成長，才能在下次遇到類似問題時解決問題。

考慮清楚為什么會形成超大的類？
可以通過哪些方法對業(yè)務(wù)進(jìn)行拆分，以達(dá)到拆分的效果？
拆分完成之后怎么判斷拆分的是否合理？

2. 問題分析

2.1 怎么形成的超大類

剛開始編寫這個文件的時候，我相信作者肯定是已經(jīng)想過了這個類要負(fù)責(zé)什么，哪些業(yè)務(wù)應(yīng)該在這個類中，這個類與上下游的關(guān)系是什么樣的。但是最初在第一次業(yè)務(wù)變更時有一點不太應(yīng)該在本類中加進(jìn)來的業(yè)務(wù)代碼，但跟本類有這強聯(lián)系的代碼就直接加。之后總有類似的事情發(fā)生，總有不是強相關(guān)，但又有關(guān)系的代碼加入進(jìn)來。導(dǎo)致代碼隨著業(yè)務(wù)不斷地變化與調(diào)整，而逐漸的陷入混亂。

所以，不必?fù)?dān)心業(yè)務(wù)代碼不會增長，它的增長是不受控制的。就像物理學(xué)中的熵增定律一樣，在一個封閉系統(tǒng)中，如果沒有外部做功，它就會逐漸陷入混亂。

2.2 用什么進(jìn)行業(yè)務(wù)治理？

業(yè)務(wù)代碼的增長，隨后陷入混亂是必然的，這件事是不是讓人感到這個問題就無解了。因為不管改多少遍都會陷入混亂，在一個無法解決的問題上人們總是會感覺到無力，從而喪失解決從根本上解決問題的力量。

不要使用上帝類，在DDD中有上帝類的概念。上帝類就是在一個類中解決所有的問題，可以看到MVC模式中的Service就是上帝類的完美代表。所以，不要只用一種模式解決所有的問題。這里給出的都是思考的過程以及方式來解決問題。所以可能會感覺到泛泛之談。

這里主要思想是DDD，但是經(jīng)過了一些變形：明確服務(wù)邊界，定義服務(wù)內(nèi)容，闡述服務(wù)關(guān)系。具體到代碼拆分上：

**從業(yè)務(wù)上劃分包**：包中的業(yè)務(wù)是對于特定的業(yè)務(wù)實體的操作。
**定義包的邊界**：包中的實體發(fā)生變化，應(yīng)該以事件的方式通知其他關(guān)心的業(yè)務(wù)。而不是由本包解決所有的外部問題
**明確包與包之間的關(guān)系**：包中只負(fù)責(zé)本包該處理的業(yè)務(wù)，不負(fù)責(zé)其他業(yè)務(wù)實體的業(yè)務(wù)。例如：在下單之后，應(yīng)該以事件的方式通知倉庫，支付，物流等等去做該做的事情。而不是自己去做。

2.3 判斷拆分的是否合理？

最簡單的規(guī)則就是單一職責(zé)，拆分后的內(nèi)容是否符合單一職責(zé)。然后就是擴展到SOLID規(guī)則。

3. 解決域展示

實際解決過也是一個不斷演化的過程，接受代碼會隨著時間不斷的變化才會接受這種解決方式。

第一階段：facade模式

將facade類作為能力透出類，而拆分出的實際工作類作為業(yè)務(wù)功能類。例如：策略部署其實可以分為策略定義和策略的使用，就可以使用facade類向外暴露接口能力，然后策略定義一個類，測錄使用一個類。

第二階段：劃分領(lǐng)域?qū)ο?/h2>

進(jìn)一步就是就是將拆分出的兩個實現(xiàn)類再拆分為：工具類，服務(wù)類，外部事件處理類，領(lǐng)域事件類。從名字就可以知道它這些類的意義。

4. 總結(jié)

業(yè)務(wù)治理是長期工作，需要理解問題產(chǎn)生的原因才可以真正的解決問題。