1.引子
我們現在一般開發一個系統，常用的就是三層架構，如SSH、SSM。一般分成三層。接口層、服務層和持久層。另外可能還有其他的一些配置。每一個系統都不完全一樣。但是又基本一樣。都是上面常見的三層架構。最初寫代碼的時候。大家都這麼分層，也就這麼寫。突然後一天，問為啥這麼分層。還真不太好回答。這分層的好處和不好的地方有哪些？好處可能很多，不然也不會大家都這麼用。我開始學習編程的時候就是三層架構了。但是不太好對方大家可能就深有感觸。一般工作中。都是在原有系統上面繼續開發。有時候會有機會負責一個新系統的搭建，系統架構的設計。一般系統都是在三層架構上面累代碼。我原來開發過一個系統，一個傳統的項目。不用說也是三層架構，這個系統開發了好長時間，需求不斷在累加。功能也越來越多。啟動一次的需要好久。機器也有點吃不消（可能就內存溢出），有一天。老闆說需要把系統的功能拆分了。搞微服務。微服務很流行，互聯網公司都在搞。需要就需要拆分系統。我本身以為。很簡單，只要把代碼拆出來就可以。事實上也是這樣，確實把代碼拆出來就可以。但是當我真正拆分代碼的時候。發現我拆不出來。代碼太凌亂了。依賴太嚴重了。相互互相的依賴。功能層層的依賴。那一次我拆分代碼高了一週。移除一點。編譯報錯修改，沒有問題啟動，找不到類在修改。這個時候回想。一直強調的高內聚，低耦合那。怎麼還是這麼難。搞微服務好，最起碼不會這高的耦合了吧。然後之後就把系統好不容易拆分出來。搞成兩個系統。然後又過了一段時間。隨著需求的不斷增加。這兩個系統也在變大。突然，發現即使你把系統拆了，成微服務（姑且可以這麼說吧），但是開發還是原來的模式。大家在開發的時候。service還是都在一塊。依賴還是很嚴重。可代碼不就是這樣，不依賴怎麼寫。我這個功能需要你的那個功能。我不依賴怎麼辦。後來發現，原來高微服務還是走的老樣子。只不過相當於原來是多個功能的系統，現在拆成了多個系統。其他的還是老樣子。不過耦合度確實低了，只不過是從大範圍來說。三層結構發現。所有的業務邏輯都在service層。所以service也最臃腫，耦合太高。但是也沒有更好的辦法。只能從代碼規範，儘量減少耦合。
2.設計
產品的需求處理，之後我拿到了需求文檔。我看完了。有問題也找產品搞定了。於是我打開數據庫，邊想，邊設計表結構。於是經過我一天的忙碌的。表結構設計處理了。然後找個時間，拉上領導其他人來review一下吧！會上領導踴躍發言，這塊少了，那塊如果有異常情況怎麼辦，還有中情況沒有考慮好。會後，我有修改了一下設計。修改了表結構。在次review。重複....終於沒有問題了。可以開始敲代碼了。就這樣每個需求就是這樣的流程。
設計review
3.換個角度
有一天，聽別人的技術設計review。發現那哥們。一上來不看流程圖，不看錶結構。花了幾個大圈。每個圈中還有幾個小圈。就這樣講了半天。結束了沒有開到表結構。大家到時提了不少問題。review後幾天，再一次review。發現這次有表結構了。review很快。感覺他設計的表結構。都沒有什麼大的問題。一些小的，不太常見的場景都包含在裡面了。 感覺有點不一樣。後來找了那個哥們聊了一下。說：原來我都是從數據庫模型入手。然後一步一步的將整個項目的模型搭建起來。現在我們可以從需求戶或者說從功能入手。先不考慮任何表結構設計。不要想著這個地方需要幾張表。什麼關係，是一對多，還是多對多，我需要設計幾張表等。先從需求和功能入手。將需求劃分。然後在把不同的需求拆分成一個個小的需求點。那些是主要功能，那些是次要的功能。那些是為這些主要和次要功能來服務的。拆分完了。和大家review完沒有問題。沒有遺漏的地方了。然後在根據一個個主要的功能點來設計主要的表。以及為了服務主要功能的次要的或者支持的表。我突然發現。這種設計和原來的剛好相反。於是我決定以後也用種設計。
4.嘗試
今天領導讓我參與開發一個新的系統。拿到需求了。我想起上次的談話。我決定試一下。我看完需求，知道要做什麼事。然後，也畫了幾個圈。主要功能、次要功能、支持主要和次要的功能。然後主要功能中在細分：主要、次要、支持的。等等。設計完我也畫了一個圈。針對每一個圈中圈中的功能詳細的分析。然後那次review上面果然大家的問題。我基本都可以打上來了。有點小喜悅。領導還說對業務理解的挺透徹的。考慮的也挺全面的。
5.敲代碼
設計完成了，開始敲代碼了。於是還是三層的架構，還是老樣子的開發。突然，想去看一下原來那哥們的開發項目。一看，在原來的service中又增加了一層。叫domain。domain中就是上次他設計review中大圈中的功能。每一個大圈一個包。這個功能的所對應的表的操作都在這裡。然後原來的service層中有多個domain的service。這個原來是在三層的基礎上有添加一層。把原來service層臃腫給拆分了。後來詳細看了發現，domain層的service不能調用其他domain層的service。但是原來service層暫時叫application層可以調用多個domain層的東西。並且發現每個層都是自己層的實體。application層要bo，domain層叫do，持久層叫po等。看完後，有點明白，這樣domain層可以完全解耦了。原來service層的功能拆分到domain層了。而application層僅僅是將各個有domain層做了整合和編排。好像會減少代碼的臃腫了。於是我決定也用這種模式。
6. 後話
後來我知道了，這種設計叫DDD（領域驅動設計）。於是趕緊找度娘了一下，DDD原來裡面有這麼多東西呀。主要功能 核心域 支持的叫支撐域，常用的叫通用域。還有實體，值對象。好多的東西呀。不過越看越有點迷失了。好多名詞。好多概念的東西呀。
7.題外話
寫了這麼多，感覺好多廢話，有點抱怨，發牢騷的感覺。DDD有許多名詞。落地感覺有點難，網上的概念很多。但是就是還是需要去實踐的。後面在慢慢的講DDD了，我也是才開始學。只是把學習過程記錄一下。感覺這次都是大片片的文字。沒有貼圖，沒有畫圖。僅貼了一張圖，系統推薦的。不知道大家會不會看到這。想多了不管了。
記錄一下過程，僅此而已。
閱讀更多 閒著沒事聊會 的文章
