今年的DDD Exchange大會在倫敦如期舉行，Udi Dahan在大會上的一場演講中從一種不同的角度對業務邏輯進行了剖析。他表示：近三十年來，重用已經成為了一種口號，它幾乎可以套用在系統開發中的每一個環節上。但重用其實是一種砒霜，極少量的使用可以用于治療，而一旦過量就會致命。

\\

Dahan是SOA與DDD方面的業界權威，他首先描述了重用思想的發展。當面向對象思想開始流行之時，重用的概念在其中扮演了一個重要的角色，但在實際應用中由于對象結構層次的使用沒有得到良好的制約，導致出現了大量的緊耦合問題。在那段時間之后的5至10年內，面向組件的設計開始冒頭，它著重承諾了可重用組件的地位，但重用還是沒能成為拯救我們的靈丹妙藥。隨后在軟件設計中又出現了SOA與微服務技術，它們都著重強調了重用的重要性。但經過了這些年的經驗之后，Dahan拋出了這個疑問：如果重用從沒有真正地起到作用，又怎能期望它會在當下創造奇跡呢？

\\

將重用視為一種糟糕的主意，這種看法并不鮮見。Dahan在這里引用了Ted Neward的思想，后者在企業計算十大謬誤的基礎上又額外補充了一條：業務邏輯能夠、也應該實現集中化。Dahan以一個簡單的規則為例：某種名稱必須限制在40個字符之內。那么應當在哪里強制實施這一規則呢？通常來說，我們一般會在UI、業務邏輯以及數據庫中實現這一規則，但由于實現規則的地方不止一處，一旦這條規則需要改變，問題就出現了。Dahan曾經看到過這樣一種解決方案，即通過元數據生成代碼，這意味著只需在一個地方改變這條規則，就能夠自動重新生成修改后的代碼。但以他的經驗來看，這種做法多半不會成功。從根本上說，問題不在于這條規則在多個地方實現，而在于難以找到所有能夠改變這一規則的地方。Dahan提出了一種解決方案，他建議使用源代碼控制處理這一問題。首先為這一規則創建一個issue，然后將所有用于處理這一規則的源代碼進行一次整體提交，并將它與這個issue相關聯起來。如此一來，一旦需要改變這一規則，很容易就能夠找到實現這一規則的所有代碼：

\\

當某條規則改變時，就到源代碼控制系統中去找

\\

軟件架構并非一種簡單的二維問題，不可能通過一個簡單的圖描述一個完整的架構。Dahan引用了Philippe Kructhen所提出的4+1架構視圖模型，Philippe認為將整個架構簡化為一個單一的視圖是不可能的，必須將架構的不同方面封裝在不同的視圖中，才能夠處理所有的復雜性。在Dahan看來，微服務思想的一個問題在于它試圖以同一種視圖表現所有環節，開發、邏輯、過程乃至硬件單元都被壓縮在一個單一視圖之內，他認為這會使服務的約束顯得過于沉重。

\\

Dahan認為以下場景是比較適合使用微服務的：當你需要測試新的某個業務用例，需要進行快速開發，并且可以獨立地部署該方案的實現時，此時就是使用微服務的良機。但他同時也提到，一旦證實了這一業務用例能夠正常運作，對原始的實現進行重寫是十分重要的，而且必須事先征求業務人員的同意。

\\

去年晚些時候，Dahan曾對微服務在企業中的應用進行了一次具有批判性的審視。

\\

明年的DDD Exchange大會預計于2016年6月10日舉辦，現已開放注冊。

\\

查看英文原文：Udi Dahan on Reuse in Business Logic and Microservices

總結

以上是生活随笔為你收集整理的Udi Dahan对于业务逻辑重用以及微服务方面的观点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。