摘要

習慣了MVC模式，習慣了敏捷開發，習慣了了小步快跑，還適合談論領域驅動開發嗎。領域開發是否就是慢節奏的開發，
本文結合自己的開發經歷，和大家聊聊這個話題。

#一.業務程式碼是如何寫爛的#
java web開發通常都是mvc模式，從早期的ssh逐漸到Spring+ Mybatis。所以通常一個工程的專案結構圖就是

• controller
• service
• manager
• dao

問題1： bean的職責不清

對應的bean就是
PO/DO（Persistence Object/Data Object）：與資料庫表結構一一對應，通過 DAO 層向上傳輸資料來源物件
DTO（Data Transfer Object）:資料傳輸物件，Service 和 Manager 向外傳輸的物件。
BO（Business Object）： 業務物件。可以由 Service 層輸出的封裝業務邏輯的物件。一般不需要，
Query：資料查詢物件，各層接收上層的查詢請求。
VO（View Object）： contoller層對外提供的

一般至少有PO/DTO/VO 三層結構，但是對於有些專案結構，業務比較簡單，就是CRUD,有些開發人員就只有兩層，controller到dao層就完了，然後bean的定義也特別混亂，隨意建立，導致bean漫天飛，通常除了自己明白其中的含義，其他人都不明白，複用性極差。

問題2：程式導向的設計
此外 bean中都是屬性，除了equals方法就都沒有了。雖然有介面和實現，但是按照這樣一套寫出來的程式碼基本上和麵向過程寫的程式碼沒有什麼區別。這種開發方式bean類只有屬性，沒有行為。這樣就會導致某一個實體的變更會散落在各個service中，而不是這個領域實體中。

問題3：不考慮業務模型
現在都是敏捷開發，導致開發人員也變得浮躁了，不分析或者草率分析需求，拿到就是幹，隨著業務迭代，開發人員增加，每個人各寫一套，關於一個名詞的定義都能有好幾套寫法，sql查詢可能會分散到好多repo中，相同的sql可能會在不同的地方寫上好幾遍。關鍵是發現之前的模型定義錯了，資料庫的ER圖設計有問題，仍然不會去更改，因為總是有新的需求會來，然後拼了命的做需求，留下一堆爛程式碼無法維護，最後連自己都不想看。

二. 領域模型是如何發揮作用的

比如說一個平臺，一開始只有一種使用者身份，後來平臺做大了，開始做交易了，區分出了商家了，和買家了。產品提了個需求開發一個商家入駐流程，吭哧吭哧開發完了。一段時間後，開始需要有中間推銷商了，一部分買家可以變成中間推銷商了，那這時候產品跟你說，不用搞入駐流程，直接賦予原來的買家額外屬性，來區分是否可以推銷商品。這時候你能同意嗎？

當然不行了，因為這個業務需求本質是就是交易，有買家，有賣家，有中間商。他們屬於交易維度的不同實體，是同一個層次的，而使用者則是不同的層次。一開始產品只會有需求說判斷是中間商就可以，沒有其他的了。等你在使用者實體上加了一堆屬性後，過了一段時間後，產品就會來跟你說，不好意思，哥們，賣家想管理中間商，需要中間商提供一些資質，你再幫我加幾個屬性。然後你的使用者實體的模型開始無限擴張的模式了。對於產品來說，他是無所謂的，快速上線驗證，驗證了不行，換另外一條路，但是作為開發就被坑的天天加班了。

所以領域模型可以幫你解決，通常一些對於一些通用的領域，你可能很好找到對應模型設計，比如說訂單，商品，抽獎，優惠券。但是這也需要你去閱讀相關的產品文件，領域設計，當然如果你有一個靠譜的產品，你可能會輕鬆很多。而有一些不是通用領域的，所以需要你與你行業領域專家去深入聊，才能設計的出來領域模型，另外一點就是通常在一開始，會有些領域模型設計的有問題，需要不斷的思考，糾正。