資訊專欄INFORMATION COLUMN
摘要：的演進按照上述的說明，在一個單體服務中，隨著業務的不斷迭代，可能會發生什么嚴重的問題。個人認為造成這個原因的主要原因還是在于長期以來的這種模式只有縱向切分導致。
摘要mvc是一種軟件設計模式，最早由Trygve Reenskaug在1978年提出，他有效的解決了表示層，控制器層，邏輯層的代碼混合在一起的問題，很好的做到了職責分離。但是在實際的編碼實踐過程中，你會發現這個模式隨著業務的擴展，變的邏輯混亂，代碼重合度很高。這里提出借鑒DDD思想的一種新的工程結構
mvc的問題通常一個前后端分離的系統，后端工程系統結構圖通常下面這樣
1. 四層 controller/service/manager/mapper 2. 不可以同級調用 3. 上級可以知曉下級，下級不可知曉上級，也就是bean的轉化放在上級
這個分層結構職責分離是按照縱向切分的
1. 資源服務層repository是面向DB編程 2. service層是面向前端頁面編程。
也就是說，對于某一塊的業務，他沒有將邏輯抽象到一起，他只是將一次request按照縱向切分了。沒有進行橫向的業務切分。 這樣將會導致的問題 職責分散，邏輯重復度高
bean的創建太隨意，基本就是一個需求對應一些dto, vo，query bean
不同開發者對于同一個領域的東西有不同的bean，同一個開發者對于相同邏輯的bean，過了幾個月，又定義出一個差不多的bean
沒有邊界
根本沒有上下文/邊界的概念，比如說店鋪會和用戶有交互，訂單會和用戶有交互，通常在DB存儲時只會存關聯id，然后需要去取對應的名稱，其他屬性信息。這些信息的獲取，有些開發在manager層操作，然后將屬性定義到了店鋪相關的DTO中;有些放在了service層做。controller/service/manager各個層次都可以調用，沒有任何約束。
mvc的演進按照上述的說明，在一個單體服務中，隨著業務的不斷迭代，可能會發生什么嚴重的問題。
舉幾個真實鮮活的例子
分庫分表的例子 實體A是我們業務中的一個基礎的重要的實體，對應的數據表tableA,一開始業務很簡單，只有1個服務，在這個服務里面調用。后來業務擴張了，有十幾個服務了，然后十幾個服務直接查這個tableA。tableA也擴張成為了tableA,tableB,tableC。有些人覺得代碼重復度高了，將mapper/manager層拆成共通的部分打成一個jar包，然后各個微服務中引入這個jar。業務變得更加復雜了，服務擴展到幾十個了，tableA數據也有幾千萬了，這時候要做分庫分表了，怎么整。
最后花了差不多1年，涉及十幾個團隊，才把這個mapper/manager調用改掉，然后做分庫分表。
有人可能覺得這個只要在服務拆分時，避免直接調用就可以了，那再舉個其他類型的例子。
用戶等級的例子
用戶的等級，用戶的分級是很復雜的，不同的業務階段有這個不同的定義。比如一開始定義一個字段叫grade的代表用戶等級。 然后各個業務都在查這個表的字段grade進行判斷，然后產品需要改了，增加了判斷必須同時要達到什么條件才能稱作等級x。這時候你又得滿世界的改了。
DDD的工程架構那如何運用DDD的思想進行改造呢 核心思想：封裝領域內的邏輯，統一對外暴露的入口，防止業務邏輯泄露。
在mvc縱向切分的基礎上，增加一層領域的橫向切分
同一個工程里面，領域之間的調用只能通過domainService,這樣可以屏蔽領域內的數據庫是如何持久化的，業務邏輯是如何判斷的、算法是如何實現的。 service之間可以直接調用。
領域內還是縱向切分，安裝mvc分層結構。
上面的只是一個草圖，我們真實的結構圖比這要稍微復雜些。領域內會區分領域對象，領域服務，基礎設施層。這樣在領域內進行指責分離，不過從實際的執行過程中領域內的比較細節，執行起來ROI比較低，推薦大家可以先按這套執行。
畫外音：估計有些程序員看到這個工程結構變化呵呵一笑，覺得沒多大價值，沒什么改變必要。
這種工程的結構劃分從提出來的到真正被我們團隊成員接受的時間周期差不多是8個月。 原因大概是這么幾類
引入新的分層，太復雜了，增加了代碼復雜度
我這塊業務很簡單，CRUD就行了，沒涉及到服務之間的交互。直接mvc一條道走到黑就可以。
如果你看這篇文章也是這種感受，不妨花點時間看下你們業務的代碼，看看重復度有多高，看看邏輯有多散亂。你就會明白。
DDD工程的演進DDD工程的演進也就是服務的拆分了，放到下期講。
總結很多DDD的文章都在說傳統的編程方式是面試數據庫編程，導致對象中只有getter,setter，也就是貧血模型，貧血模型是沒有業務邏輯，面向過程設計，不符合面向對象設計原則。
對于這個結論我是同意的，但是對于造成的原因不是很同意。個人認為造成這個原因的主要原因還是在于長期以來的MVC這種模式只有縱向切分導致。如果結合橫向切分，有沒有DDD也無所謂。這里再引用一下驅動方法不能改變任何事情這段話，如果你能深入理解職責、封裝。并隨著業務的迭代，不斷的重構你的代碼，那么你不需要什么DDD,或者其他方法論。
使用職責、封裝和組合； 以接口的視角思考，即“人們如何使用我的組件？”； 使用相關技術寫好代碼，包括可讀性、信息性、簡潔、自描述，盡量避免顯式地使用模式； 有能力回答特定業務的“本質”；“本質”是一個模型，但不意味著類和方法，它意味著回答問題“這個業務如何真正地工作？”
因為這些約束，都是強迫你去思考，去做職責的思考，去做模塊的封裝。如果你/你團隊成員已經領會其中的道理并很好的運用，還需要這些條條框框干嗎呢？
下一篇領域與微服務劃分，欲知后事如何，請聽下回分解。
相關閱讀
可落地的DDD(1)-目標討論
關注【方丈的寺院】，第一時間收到文章的更新，與方丈一起開始技術修行之路
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/6882.html
摘要：中的事件的一個，我暫且理解為一個中的和這兩個屬性已經在框架中直接掛載在了對象上，歸功于曾老師。 CQRS是啥？DDD又是啥？ 這兩個概念其實沒什么神秘的，當然此文章中的這兩個概念以曾老師的課程為準（關于CQRS和DDD的標準概念，google上已經很多了，不再贅述。） DDD(Domain Driven Design)，領域驅動設計開發。 DDD和OOP有什么同嗎？其實就我個人經驗來說...
摘要：最近發現文章老是被竊取，有些平臺舉報了還沒有用。最后不了了之，產品很配合，但是內驅力不強。為什么內驅力不強，因為給他帶來的收益不夠。所以在千個團隊中實行可能有千套不同的方案。最近發現文章老是被竊取，有些平臺舉報了還沒有用。請識別我的id方丈的寺院。 摘要 DDD領域驅動設計，起源于2004年著名建模專家Eric Evans發表的他最具影響力的著名書籍：Domain-Driven Design...
摘要：作者小傅哥博客沉淀分享成長，讓自己和他人都能有所收獲接下來還需要把我們創建的工程模板以及數據服務配置到中，這樣在插件啟動的時候就可以把我們自己插件啟動起來了。作者：小傅哥博客：https://bugstack.cn沉淀、分享、成長，讓自己和他人都能有所收獲！???? 接下來還需要把我們創建的工程模板以及數據服務配置到 plugin.xml 中，這樣在插件啟動的時候就可以...
摘要：問題來了，我們到底還在用嗎答案是，不全用。后者是初始化的配置，主要是的配置。啟動類測試啟動項目后，在瀏覽器里面輸入。通過查詢已裝載的，并且支持該而獲取的。按照前面對的描述，對于而言，這個必定是。的核心在的方法中。 之前已經分析過了Spring的IOC(《零基礎帶你看Spring源碼——IOC控制反轉》)與AOP(《從源碼入手，一文帶你讀懂Spring AOP面向切面編程》)的源碼，本次...
摘要：而程序員和醫生律師的不同點在于持續學習上。兩個小問題是需要收費，一年大概刀圖書都是英文的。的視頻基本都有英文字幕，配合作者的，英語不好的同學學習也沒有問題。英文好的有技術功底的同學多發表一些觀點，其他的同學都 摘要： 行業發展得太快，你必須學習，純靠經驗積累行不通，技術淘汰的速度遠大于你經驗積累的速度。 非雞湯：不要和程序員談自己的編程歷史，很多的經驗在今天已經不適用了。只要2-3年...
閱讀 2432·2021-10-09 09:59
閱讀 2184·2021-09-23 11:30
閱讀 2598·2019-08-30 15:56
閱讀 1150·2019-08-30 14:00
閱讀 2945·2019-08-29 12:37
閱讀 1260·2019-08-28 18:16
閱讀 1661·2019-08-27 10:56
閱讀 1028·2019-08-26 17:23
