架構漫談（八）：從架構的角度看如何寫好代碼

上篇：架構漫談（七）：不要空設架構師這個職位，給他實權

　　在第六篇文章中，咱們得出一個結論，軟件架構實際上包括了：代碼架構，以及承載代碼運行的硬件部署架構。實際上，硬件部署架構最終仍是由代碼的架構來決定。由於代碼架構不合理，是沒法把一個運行單元分拆出多個來的，那麼硬件架構能分拆的就很是的有限，整個系統最終很難長的更大。

　　因此咱們常常會據說，重寫代碼，推翻原有架構，從新設計等等說法，來講明架構的進化。這實際上就是當初爲了完成任務，沒有充分思考所帶來的後果。這也並非架構進化的事情，而是我的對問題領域的逐漸深刻理解的過程。因此有必要再討論一下，代碼的架構應該是怎樣的。

　　本文會在以前幾篇文章的基礎上，進一步探討如何把架構的思考進行落地，細化到咱們代碼的實踐當中，儘可能不要讓代碼成爲系統長大的瓶頸，下降架構分拆的成本。

　　在前面咱們提到，軟件其實是對現實生活的模擬，虛擬化。這是一個很是重要的前提，直接決定了咱們的代碼應該分爲幾部分。結合每一個部署單元所承擔的責任，能夠明確的拆分爲兩個不一樣的責任：

1. 表達業務邏輯的代碼。不少人把這部分叫作Domain Logic，或者叫Domain Model。這部分實際是來源於生活的，必須保持和現實生活中的切分一致，並不是人爲的抽象而成。

2. 對用戶提供訪問並保存業務邏輯運行結果的代碼。計算機的狀態保存有一個缺陷，本機保留業務運行結果有很大的問題，通常都在外存儲設備上保存，也便於擴展。

　　因此單個部署單元的代碼能夠分爲兩個部分，以下圖所示：

　　從這個圖中能夠看出，軟件代碼的相關利益人爲運行時的訪問人員和存儲設備。而service的代碼是最複雜的，須要服務於三方，代碼人員的負擔是最重的。爲了把這三方的變化對service的影響降到最低，對於service還必須進一步的分拆爲三個部分，讓每個部分都可以獨立的變化，這樣這三方的變化就不會產生連鎖響應，下降成本。以下圖所示：

　　這樣，就劃分紅了幾個責任：

1. Service就專一於user的需求，並組合Glue Code提供的服務完成需求。

2. Glue Code專一於組合business的調用，管理Business裏面對象的生命週期，而且經過Repository保存或加載Business的狀態

3. Business專一於實現業務的核心模型。

4. Repository專一於數據的保存，並和存儲設備一一對應。

　　你們注意看，仍是樹形架構。而且左側的主要須要計算機的相關理論知識，而且要直接面對用戶的需求。右側的更多的須要面對業務的核心。只要這幾塊的開發人員互相商量好了接口定義，這幾個部分的開發就能夠並行的進行，極大的提高開發的效率，縮短開發的時間。要作好這幾部分，還須要注意，邏輯只容許存在於Business中，Service、Glue Code、Repository都不容許存在業務邏輯。爲何呢？首先咱們來看看什麼叫業務邏輯。

　　什麼叫業務邏輯？

　　首先這個定義的前提是指軟件代碼中的邏輯，不是現實生活中的邏輯。在軟件代碼中，不需縮進和計算的順序調用，包括縮進的代碼目的是catch exception的，都不算邏輯，除此之外都是邏輯。如下用嚴格的順序調用來指代這種代碼。由於順序調用是計算機的特性，由編譯器來決定的，固然最本質的是由於咱們計算的基礎都是圖靈機。在現實生活中，順序調用也是邏輯，你們不要和咱們這裏說的業務邏輯相混淆。

　　爲何說除了Business代碼中有邏輯之外，其餘地方不能有邏輯呢？ 咱們每一個部分分別分析：

1. 若是service裏面不是嚴格的順序調用，有不少分支，那麼說明這個service作了兩件或者兩件以上的事情。必須把這個service分拆，確保每一個service只作一件事情。由於若是不這麼分拆的話，一旦這個service中的某各部分發生變更，其餘的部分的執行一定會受影響。而肯定到底有哪些影響的溝通成本很是高，其餘相關利益方沒有動力去配合，咱們每每不會投入精力仔細評估。最後上線會出不少不可預料的問題，最終會致使損失用戶的利益，而且確定會致使返工，損壞本身的利益。若是是有計算的邏輯的話，好比受益計算，訂單金額計算等，那麼這部分應該是Business代碼須要完成的，不能交給service代碼來實現。

2. Glue Code裏面若是不是嚴格的順序調用，同理會和service同樣遇到一樣的問題。

3. Repository裏面若是不是嚴格的順序調用，包括存儲訪問的代碼裏面（好比SQL），會致使邏輯進入到存儲設備中。存儲設備的主要目的是拿來存儲的，一旦變成了邏輯計算的主體，就會致使存儲設備沒法經過增長機器的方式橫向擴展長大。這個時候就沒有架構了，只能換性能更好的機器，這個叫scale up。只有scale out才能算架構。

　　以上都會致使架構沒法快速的橫向擴展和分拆，而且增長了修改的成本，這些是不符合開發人員以及業務的利益的。

　　這麼作的好處有哪些呢？

1. Service、Glue Code、Repository裏面的代碼是嚴格的順序調用，那麼這些代碼只要作連通性測試便可，不須要單元測試。由於這些代碼都須要和不少上下文打交道，很難作單元測試。這樣纔算是真正的組合。

2. Business不訪問任何上下文，不訪問任何具體的設備，因此這部分代碼是很是容易寫單元測試的，而且單元測試必須100%覆蓋。由於其餘地方沒有業務邏輯，因此一旦有問題，就能夠判定是Model的問題，單元測試確定能夠發現。若是單元測試沒有發現問題，那麼單元測試必定有問題。線上問題的模擬也就變得很是的簡單，單元測試也可以獲得進一步的補充。

3. Repository很容易按照存儲設備自己的最小訪問粒度來完成工做，好比DB，徹底能夠作到單表訪問。由於這個時候存儲設備只關心存取數據，徹底和業務沒有關係。作表的分拆也是很是容易的事情，存儲設備經過增長機器就能夠橫向擴展長大。不少人會擔憂說，沒有了join，訪問DB的次數是否是更多了，會致使性能降低？ 按照如今網絡的條件，網絡訪問和Disk IO訪問的差距已經不大了，合理的設計下，多訪問幾回DB並不會致使這個問題。另外若是多臺DB的話，還能經過並行加速訪問。

4. 因爲Service、Glue Code、Repository代碼簡單了，纔可讓咱們的開發人員投入更多的時間研究業務，畢竟這部分纔是軟件所真正服務的對象。

　　咱們再來看一個實際的例子，以下圖所示：

　　Manager類實際就是Glue Code。有幾個注意點須要說明一下：

1. 不能把Business Model當作數據對象來處理，Model關心的其實是業務行爲，數據只是是這些行爲的結果。因此Glue Code須要把Model轉換爲Entity，Entity和存儲設備裏面的存儲粒度一一對應。好比在DB中，每一個Entity對應一張表，而且跟着表的變化而變化，這樣就保證存儲的變動不會影響Model。一樣Service和用戶之間的數據交互，也是不會和Model之間相關的，確保用戶的需求變化，不會影響到Model。由於用戶的需求變化是最頻繁的，沒有邏輯，可讓我快速的知足業務的需求。

2. 在Service這裏，最好不要考慮代碼重用。由於當多個不一樣的角色訪問同一個接口，一旦某個角色的需求發生了變化，就會要求開發人員去修改。而這個修改每每會影響到其餘的角色，須要這些角色一塊兒配合來肯定是否受影響，可是這些角色由於沒有需求，每每不會配合。這樣就給開發人員形成了不少沒必要要的溝通，成本是很是高的。最終都會致使線上Bug，影響最終的用戶。因此儘可能給不一樣的角色不一樣的Service，避免重用，下降溝通成本。不少人會說這樣Service不就太多了嗎？ 這樣Service註冊，查找等管理需求就出現了，Service治理中心就是來解決這個問題的。由於Service裏面沒有邏輯，因此開發和管理很是的簡單，能夠快速應對業務的變化。咱們只有更快地變，更容易的變，才能更好地應對變。

3. Business Model是必需要重用的，一旦發現重用出現問題，那麼說明Business Model的識別出現了問題，這是一個咱們要從新思考Model的信號。Business Model必須是一個完美的樹狀，若是不是，也說明Model的識別出了問題。

　　在實際操做中，Service、Glue Code、Repository不能有邏輯，實際上和不少人的觀念是衝突的，認爲這個根本作不到。作到這一點須要不少的學習成本，可是必定能夠作獲得。當發現作不到的時候，能夠判定是業務的分析出了問題。好比不應合併的合併了，不應計算的計算了。這個問題必定有辦法解決的，作不到都是理由，無非是想早點把本身的工做結束罷了。雖然剛開始會比較困難，一旦把這個觀念變成自覺，開發的質量和效率立刻就能高好幾個級別。

　　個人游泳教練曾和我說過這些話，我至今記憶猶新：「業餘選手，越想從水裏浮起來，就越想把頭擡起來，身體反而沉下去。只有克服恐懼，把頭往水裏壓下去，身體纔可以從水裏浮起來。真正專業的習慣每每是和咱們平常的行爲相反的」。

　　咱們真正想快速的完成代碼工做，就要克服本身對時間的恐懼，真正的去研究業務的問題，相關stakeholder的利益，把這個變成咱們的習慣。寫代碼的時候讓該出現邏輯的地方出現邏輯，讓不應出現的地方不能出現。一旦不應出現的地方出現了邏輯，那麼要立刻意識到，這個地方是一個坑，這個問題必定和業務的分析不透徹有關係。

　　不少人可能會把這個作法和Martin Fowler曾經提出過充血模型和貧血模型來比較，和Domain Driven Design來比較，其實沒有必要。這個分拆徹底是從軟件所解決的問題，根據軟件架構推導出來的，不少地方和兩位前輩的觀點是一致的，可是並不徹底等同。

　　以上只是針對單一的Service部署單元的分析，擴展開去，對於其餘的部署單元也是相似的。每一個單元的下一級均可以認爲是Repository，每一個單元的上一級均可以認爲是User。這些實踐在我本身的項目中都有用到，很是的有效，迭代的速度很是的快。不少人擔憂Business Model建很差，其實不要緊，剛開始能夠粗糙一點，後續能夠慢慢的完善。這個架構已經隔離好了每一個部分的變化對其餘部分的影響，變化成本都在可控的範圍以內。

　　下篇：架構漫談（九）：理清技術、業務和架構的關係