在這個(gè)萬物互聯(lián)的時(shí)代，物聯(lián)網(wǎng)業(yè)務(wù)蓬勃發(fā)展，但也瞬息萬變，對(duì)于開發(fā)人員來說，這是一種挑戰(zhàn)，但也是一種“折磨”。

在業(yè)務(wù)發(fā)展初期，因?yàn)闀r(shí)間有限，我們一般會(huì)遵循“小步快跑，迭代試錯(cuò)”的原則進(jìn)行業(yè)務(wù)開發(fā)，用通俗的話來說就是“no bb，先上了再說”，對(duì)于開發(fā)人員的具體實(shí)現(xiàn)，就是“腳本式”的開發(fā)方式，或者說是數(shù)據(jù)的 CURD，這樣的開發(fā)方式，在項(xiàng)目早期沒什么問題，但隨著新業(yè)務(wù)的不斷加入，業(yè)務(wù)迭代的頻繁，我們會(huì)發(fā)現(xiàn)，現(xiàn)在的業(yè)務(wù)系統(tǒng)變得越來越冗雜，新加一個(gè)需求或者改一個(gè)業(yè)務(wù)，變得無比困難，因?yàn)闃I(yè)務(wù)實(shí)現(xiàn)彼此之間模糊不清，業(yè)務(wù)規(guī)則在代碼中無處不在，開發(fā)人員也就無從下手。

那怎么解決上面的問題呢？可能很多人會(huì)說“你這代碼不行，重構(gòu)呀”，是的，我們發(fā)現(xiàn)了項(xiàng)目中的“壞代碼”，比如一個(gè)類上千行，一個(gè)方法幾百行，于是我們把一些代碼抽離出來，做一些內(nèi)聚的實(shí)現(xiàn)，代碼規(guī)范做一些調(diào)整，但這樣只是解決現(xiàn)在項(xiàng)目代碼中的問題，下次項(xiàng)目迭代的時(shí)候，你并不能保證寫的新代碼是符合規(guī)范的，而且最重要的是，重構(gòu)并不能在業(yè)務(wù)代碼上給一個(gè)定義，什么意思呢？比如你重構(gòu)一個(gè)方法，你只能從技術(shù)的角度去重構(gòu)它，并不能從業(yè)務(wù)的角度去重構(gòu)，因?yàn)樵谡麄€(gè)業(yè)務(wù)系統(tǒng)“混亂”的情況下，你無法保證自己的“清白”。另外還有一點(diǎn)，即使你重構(gòu)了它，但對(duì)于新加入的開發(fā)人員來說，他并不能理解你重構(gòu)的目的，換句話說，就是如果他要使用或改這個(gè)方法，他完全不知道能不能使用或者使用了會(huì)不會(huì)影響其他業(yè)務(wù)，說白了就是，業(yè)務(wù)的邊界不明確。

那如何定義業(yè)務(wù)的邊界呢？答案就是運(yùn)用 Eric Evans 提出的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Design，簡稱 DDD），關(guān)于 DDD 的相關(guān)概念，這邊就不敘述了，網(wǎng)上有很多資料，需要注意的是，DDD 關(guān)注的是業(yè)務(wù)設(shè)計(jì)，并非技術(shù)實(shí)現(xiàn)。

物聯(lián)網(wǎng)業(yè)務(wù)如何應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)？這其實(shí)是個(gè)大命題，該怎么實(shí)現(xiàn)？如何下手呢？我找了我之前做的一個(gè)業(yè)務(wù)需求，來做示例，看看“腳本式”的實(shí)現(xiàn)，和 DDD 的實(shí)現(xiàn)，前后有什么不太一樣的地方。

腳本式的開發(fā)

業(yè)務(wù)需求：針對(duì)物聯(lián)網(wǎng)卡的當(dāng)前套餐使用量，根據(jù)一定的規(guī)則，進(jìn)行特定的限速設(shè)置。

需求看起來很簡單，下面要具體實(shí)現(xiàn)了，首先，我創(chuàng)建了三張表：

speed＿limit：限速表，包含用戶 ID、套餐 ID 等。

speed＿limit＿config：限速配置表，包含限速檔位，也就是套餐使用量在什么區(qū)間，限速多少的配置。

speed＿limit＿level：限速級(jí)別表，包含限速的單位和具體值，主要界面選擇使用。

然后再創(chuàng)建對(duì)應(yīng)“貧血”的模型對(duì)象（沒有任何行為，并且屬性和數(shù)據(jù)庫字段一一對(duì)應(yīng)）：

public class SpeedLimit ｛

private Long id；

private Integer orgId；

private Long priceOfferId；

／／getter setter．．．．

｝

public class SpeedLimitConfig ｛

private Long id；

private Long speedLimitId；

private Double usageStart；

private Double usageEnd；

／／getter setter．．．．

｝

public class SpeedLimitLevel ｛

private Long id；

private String unit；

private Double value；

／／getter setter．．．．

｝

好，數(shù)據(jù)庫表和模型對(duì)象都創(chuàng)建好了，接下來做什么呢？CURD 啊，界面需要對(duì)這些數(shù)據(jù)進(jìn)行查看和維護(hù)，所以，我創(chuàng)建了：

SpeedLimitMapper．xml：數(shù)據(jù)庫訪問 SQL。

SpeedLimitService．java：調(diào)用 Mapper，并返回?cái)?shù)據(jù)。

SpeedLimitController．java：接受前端傳遞參數(shù)，并調(diào)用 Service，封裝返回?cái)?shù)據(jù)。

簡單看下SpeedLimitService．java中的代碼：

public interface SpeedLimitService ｛

List＜SpeedLimit＞ listAll（）；

SpeedLimitVO getById（Long id）；

Boolean insert（Integer orgId， Long priceOfferId， List＜SpeedLimitConfig＞ speedLimitConfigs）；

／／．．．

｝

CURD 流程沒啥問題吧，數(shù)據(jù)維護(hù)好了，接下來要進(jìn)行限速檢查了，我們目前的實(shí)現(xiàn)方式是：有一個(gè)定時(shí)任務(wù)，每間隔一段時(shí)間批量執(zhí)行，查詢所有的限速配置（上面的speed＿limit），然后根據(jù)用戶 ID 和套餐 ID，查詢出符合條件的物聯(lián)網(wǎng)卡，然后將卡號(hào)丟到 MQ 中異步處理，MQ 接受到卡號(hào)，再查詢對(duì)應(yīng)的限速配置（speed＿limit以及speed＿limit＿config），然后再查詢此卡的套餐使用量，最后根據(jù)規(guī)則匹配，進(jìn)行限速設(shè)置等操作。

MQ 中的處理代碼（阿里插件都已經(jīng)提醒我，這個(gè)方法代碼太長了）：

為什么代碼不貼出來？因?yàn)槔锩娴拇a慘不忍睹啊，if．．else．．的各種嵌套，所以，還是眼不看為凈。

好，到此為止，這個(gè)需求已經(jīng)“腳本式”的開發(fā)完了，我們來總結(jié)一把：

條理清晰，開發(fā)效率賊高，完全符合“先上了再說”的開發(fā)原則。

數(shù)據(jù)的 CURD 和業(yè)務(wù)邏輯處理隔離開，用到的地方＿x001D＿“單獨(dú)處理”，似乎沒啥問題。

沒啥問題對(duì)吧？好，現(xiàn)在業(yè)務(wù)迭代來了，產(chǎn)品經(jīng)理發(fā)話了，說除了批量限速檢查，還需要對(duì)單卡的限速同步處理（瞎掰的），因?yàn)槭峭教幚恚晕覜]辦法發(fā)消息到 MQ 處理，只能對(duì) MQ 中的那一坨代碼進(jìn)行重構(gòu)，代碼抽離的過程中發(fā)現(xiàn)，并不能兼容新的需求，怎么搞呢？只能又重載了一個(gè)方法，把里面能抽離的抽離出來，改好之后，需求完美上線。

過了一天，產(chǎn)品經(jīng)理又發(fā)話了。

然后，我把產(chǎn)品經(jīng)理打死了。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

為了避免我和產(chǎn)品經(jīng)理打架，我需要做一些改變，就事論事，畢竟問題出在開發(fā)這邊，面對(duì)“一鍋亂粥”的代碼，我決定用 DDD 這把“武器”進(jìn)行改造它。

我們知道，DDD 分為戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)，戰(zhàn)略設(shè)計(jì)就是把限界上下文和核心領(lǐng)域搞出來，然后針對(duì)某個(gè)限界上下文，再利用戰(zhàn)術(shù)設(shè)計(jì)進(jìn)行具體的實(shí)現(xiàn)，這個(gè)過程一般是針對(duì)一個(gè)完整復(fù)雜的業(yè)務(wù)系統(tǒng)，涉及的東西很多，你可能需要和領(lǐng)域?qū)＜疫M(jìn)行深入溝通，如有必要還需畫出業(yè)務(wù)領(lǐng)域圖、限界上下文圖、限界上下文映射圖等等，以便理解。

針對(duì)限速設(shè)置的業(yè)務(wù)需求，我簡單畫了下所涉及的上下文映射圖：

可以看到，我們關(guān)注的只有一個(gè)限速上下文，物聯(lián)網(wǎng)卡上下文、套餐流量上下文和運(yùn)營商 API 上下文，我們并不需要關(guān)心，ACL 的意思是防腐層（Anticorruption Layer），它的作用就是隔離各個(gè)上下文，以及協(xié)調(diào)上下文之間的通信。

限速上下文內(nèi)部的實(shí)現(xiàn)（如聚合根和實(shí)體等），其實(shí)就是戰(zhàn)術(shù)設(shè)計(jì)的具體實(shí)現(xiàn)，關(guān)于概念這邊就不多說了，這里說下具體的設(shè)計(jì)：

SpeedLimit聚合根：毫無疑問，限速上下文的聚合根是限速聚合根，也可以稱之為聚合根實(shí)體，這里的SpeedLimit并不是上面貧血的模型對(duì)象，而是包含限速業(yè)務(wù)邏輯的聚合對(duì)象。

SpeedLimitConfig實(shí)體：限速配置實(shí)體，在生命周期內(nèi)有唯一的標(biāo)識(shí)，并且依附于限速聚合根。

SpeedLimitLevel實(shí)體：其實(shí)限速級(jí)別應(yīng)該設(shè)計(jì)成值對(duì)象，因?yàn)樗]有生命周期和唯一標(biāo)識(shí)的概念，只是一個(gè)具體的值。

SpeedLimitContext值對(duì)象：限速上下文，只包含具體的值，作用就是從應(yīng)用層發(fā)起調(diào)用到領(lǐng)域?qū)?，可以看做是傳輸?duì)象。

SpeedLimitService領(lǐng)域服務(wù)：因?yàn)樯婕暗蕉鄠€(gè)上下文的協(xié)調(diào)和交互，限速聚合根并不能獨(dú)立完成，所以這些聚合根完成不了的操作，可以放到領(lǐng)域服務(wù)中去處理。

SpeedLimitRepository倉儲(chǔ)：限速聚合對(duì)象的管理中心，可以數(shù)據(jù)庫存儲(chǔ)，也可以其他方式存儲(chǔ)，不要把Mapper接口定義為Repository接口。

以上因?yàn)椴缓迷诂F(xiàn)有項(xiàng)目中做改造，我就用 Spring Boot 做了一個(gè)項(xiàng)目示例（Spring Boot 用起來真的很爽，簡潔高效，做微服務(wù)非常好），大致的項(xiàng)目結(jié)構(gòu)：

├── src

│ ├── main

│ │ ├── java

│ │ │ └── com

│ │ │ └── qipeng

│ │ │ └── simboss

│ │ │ └── speedlimit

│ │ │ ├── SpeedLimitApplication．java

│ │ │ ├── application

│ │ │ │ ├── dto

│ │ │ │ └── service

│ │ │ │ ├── SpeedLimitApplicationService．java

│ │ │ │ └── impl

│ │ │ │ └── SpeedLimitApplicationServiceImpl．java

│ │ │ ├── domain

│ │ │ │ ├── aggregate

│ │ │ │ │ └── SpeedLimit．java

│ │ │ │ ├── entity

│ │ │ │ │ ├── SpeedLimitConfig．java

│ │ │ │ │ └── SpeedLimitLevel．java

│ │ │ │ ├── service

│ │ │ │ │ ├── SpeedLimitService．java

│ │ │ │ │ └── impl

│ │ │ │ │ └── SpeedLimitServiceImpl．java

│ │ │ │ └── valobj

│ │ │ │ └── SpeedLimitCheckContext．java

│ │ │ ├── facade

│ │ │ │ ├── CarrierApiFacade．java

│ │ │ │ ├── DeviceRatePlanFacade．java

│ │ │ │ ├── IotCardFacade．java

│ │ │ │ └── model

│ │ │ │ ├── CarrierConstants．java

│ │ │ │ ├── DeviceRatePlan．java

│ │ │ │ ├── EnumTemplate．java

│ │ │ │ ├── IotCard．java

│ │ │ │ └── SpeedLimitAction．java

│ │ │ └── repo

│ │ │ ├── dao

│ │ │ │ └── SpeedLimitDao．java

│ │ │ └── repository

│ │ │ └── SpeedLimitRepository．java

│ │ └── resources

│ │ ├── application．yml

│ │ ├── mybatis

│ │ │ ├── mapper

│ │ │ │ └── SpeedLimitMapper．xml

│ │ │ └── mybatis－config．xml

│ └── test

│ └── java

│ └── com

│ └── qipeng

│ └── simboss

│ └── speedlimit

│ ├── SpeedLimitApplicationTests．java

│ ├── application

│ │ └── SpeedLimitApplicationServiceTest．java

│ └── domain

│ └── SpeedLimitServiceTest．java

包路徑：

import com．qipeng．simboss．speedlimit．domain．a(chǎn)ggregate．SpeedLimit；／／聚合根import com．qipeng．simboss．speedlimit．domain．entity．＊；／／實(shí)體import com．qipeng．simboss．speedlimit．domain．valobj．＊；／／值對(duì)象import com．qipeng．simboss．speedlimit．domain．service．＊；／／領(lǐng)域服務(wù)import com．qipeng．simboss．speedlimit．domain．repo．repository．＊；／／倉儲(chǔ)import com．qipeng．simboss．speedlimit．repo．dao．＊；／／mapper接口import com．qipeng．simboss．speedlimit．a(chǎn)pplication．service．＊；／／應(yīng)用層服務(wù)

好，基本上這個(gè)項(xiàng)目設(shè)計(jì)的差不多了，需要注意的是，上面核心是com．qipeng．simboss．speedlimit．domain包，里面包含了最重要的業(yè)務(wù)邏輯處理，其他都是為此服務(wù)的，另外，在領(lǐng)域模型不斷完善的過程中，需要持續(xù)對(duì)領(lǐng)域模型進(jìn)行單元測試，以保證其健壯性，并且，設(shè)計(jì)SpeedLimit聚合根的時(shí)候，不要先考慮數(shù)據(jù)庫的實(shí)現(xiàn)，如果需要數(shù)據(jù)進(jìn)行測試，可以在SpeedLimitRepository中 Mock 對(duì)應(yīng)的數(shù)據(jù)。

看下SpeedLimit聚合根中的代碼：

package com．qipeng．simboss．speedlimit．domain．a(chǎn)ggregate；

import com．qipeng．simboss．speedlimit．domain．entity．SpeedLimitConfig；import com．qipeng．simboss．speedlimit．facade．model．IotCard；import lombok．Data；import java．util．Date；import java．util．List；

／＊＊

＊ 限速聚合根

＊／＠Datapublic class SpeedLimit ｛

／＊＊

＊ 限速

＊／

private Long id；

／＊＊

＊ 組織ID

＊／

private Integer orgId；

／＊＊

＊ 套餐ID

＊／

private Long priceOfferId；

／＊＊

＊ 限速配置集合

＊／

private List＜SpeedLimitConfig＞ configs；

／＊＊

＊ 是否刪除當(dāng)前限速，不持久化

＊／

private Boolean isDel ＝ false；

／＊＊

＊ 卡的限速值，不持久化

＊／

private Double cardSpeedLimit；

／＊＊

＊ 獲取限速值

＊／

public Double chooseSpeedLimit（Double usageDataVolume， Double totalDataVolume， Long cardPoolId，

Boolean isRealnamePassed， Double currentSpeedLimit） ｛

／／todo this．．．

｝

／＊＊

＊ 設(shè)置是否刪除當(dāng)前限速

＊／

private void setIsDelSpeedLimit（Double currentSpeedLimit） ｛

／／判斷當(dāng)前限速是否存在，如果存在，則刪除現(xiàn)有的限速配置

／／todo this．．．

｝

｝

上面注釋寫的比較多（方便理解），SpeedLimit聚合根和之前的SpeedLimit貧血對(duì)象相比，主要有以下改動(dòng)：

SpeedLimit聚合根并不只是包含getter和setter，還包含了業(yè)務(wù)行為，并且也不和數(shù)據(jù)庫表一一對(duì)應(yīng)。

SpeedLimit聚合根中包含configs對(duì)象（限速配置集合），因?yàn)橄匏倥渲脤?shí)體依附于SpeedLimit聚合根。

SpeedLimit聚合根中的chooseSpeedLimit方法，意思是根據(jù)某種規(guī)則從限速配置中，選取當(dāng)前要限速的值，這是限速的核心業(yè)務(wù)邏輯。

那為什么不把整個(gè)限速設(shè)置的邏輯寫在SpeedLimit聚合根中？而只是實(shí)現(xiàn)選取要限速的值呢？為什么？為什么？為什么？

答案很簡單，因?yàn)橄匏僭O(shè)置的整個(gè)邏輯需要涉及到多個(gè)上下文的協(xié)作，SpeedLimit聚合根完全 Hold 不住呀，所以要把這些邏輯寫到限速領(lǐng)域服務(wù)中，還有最重要的是，SpeedLimit聚合根只關(guān)注它邊界內(nèi)的業(yè)務(wù)邏輯，像限速設(shè)置的具體后續(xù)操作，它不需要關(guān)心，那是業(yè)務(wù)流程需要關(guān)心的，也就是限速＿x001D＿領(lǐng)域服務(wù)需要去協(xié)作的。

好，那我們就看下限速領(lǐng)域服務(wù)的具體實(shí)現(xiàn)：

package com．qipeng．simboss．speedlimit．domain．service．impl；

／＊＊

＊ 限速領(lǐng)域服務(wù)

＊／＠Servicepublic class SpeedLimitServiceImpl implements SpeedLimitService ｛

＠Autowired

private SpeedLimitRepository speedLimitRepo；

＠Autowired

private IotCardFacade iotCardFacade；

＠Autowired

private DeviceRatePlanFacade deviceRatePlanFacade；

＠Autowired

private CarrierApiFacade carrierApiFacade；

／＊＊

＊ 批量限速檢查

＊／

＠Override

public void batchSpeedLimitCheck（） ｛

List＜SpeedLimit＞ speedLimits ＝ speedLimitRepo．listAll（）；

for （SpeedLimit speedLimit ： speedLimits） ｛

List＜IotCard＞ iotCards ＝ iotCardFacade．listByByOrgId（speedLimit．getOrgId（）， speedLimit．getPriceOfferId（））；

for （IotCard iotCard ： iotCards） ｛

doSpeedLimitCheck（iotCard， speedLimit）；

｝

｝

｝

／＊＊

＊ 單個(gè)限速檢查

＊／

＠Override

public void doSpeedLimitCheck（SpeedLimitCheckContext context） ｛

String iccid ＝ context．getIccid（）；

IotCard iotCard ＝ iotCardFacade．get（iccid）；

if （iotCard ?。?null） ｛

SpeedLimit speedLimit ＝ speedLimitRepo．get（iotCard．getOrgId（）， iotCard．getPriceOfferId（））；

if （speedLimit ?。?null） ｛

this．doSpeedLimitCheck（iotCard， speedLimit）；

｝

｝

｝

／＊＊

＊ 執(zhí)行限速邏輯

＊

＊ ＠param iotCard

＊ ＠param speedLimit

＊／

private void doSpeedLimitCheck（IotCard iotCard， SpeedLimit speedLimit） ｛

／／todo this．．．

notify（iccid， speedLimit．getCardSpeedLimit（））；

｝

／＊＊

＊ 修改卡的限速值，并通知用戶

＊／

private void notify（String iccid， Double speedLimit） ｛

if （speedLimit ?。?null） ｛

／／todo this．．．

System．out．println（＂update iotCard SpeedLimit to： ＂ ＋ speedLimit）；

System．out．println（＂notify．．．＂）；

｝

｝

｝

上面的代碼看起來很多，其實(shí)干的事并不復(fù)雜，主要是業(yè)務(wù)流程：

通過SpeedLimitCheckContext上下文獲取iccid，然后獲取對(duì)應(yīng)的限速對(duì)象和套餐流量對(duì)象。

通過限速聚合根獲取需要設(shè)置的限速值（核心業(yè)務(wù)）。

調(diào)用相關(guān)接口進(jìn)行添加／刪除限速。

修改卡的限速值，并通知用戶。

以上限速領(lǐng)域模型基本上比較豐富了，后面的業(yè)務(wù)迭代只需要改里面的代碼即可。

好，我們再來看下應(yīng)用服務(wù)中的代碼：

package com．qipeng．simboss．speedlimit．a(chǎn)pplication．service．impl；

＠Servicepublic class SpeedLimitApplicationServiceImpl implements SpeedLimitApplicationService ｛

＠Autowired

private SpeedLimitService speedLimitService；

＠Override

public void batchSpeedLimitCheck（） ｛

speedLimitService．batchSpeedLimitCheck（）；

｝

＠Override

public void doSpeedLimitCheck（String iccid） ｛

SpeedLimitCheckContext context ＝ new SpeedLimitCheckContext（）；

context．setIccid（iccid）；

speedLimitService．doSpeedLimitCheck（context）；

｝

｝

應(yīng)用服務(wù)不應(yīng)包含任何的業(yè)務(wù)邏輯，只是工作流程的處理，比如接受參數(shù)，然后調(diào)用相關(guān)服務(wù)，封裝返回等，如果需要持久化聚合根對(duì)象，調(diào)用倉儲(chǔ)服務(wù)即可（可能會(huì)涉及到 UnitOfWork），另外，像限速聚合根對(duì)象的維護(hù)，也是實(shí)現(xiàn)在應(yīng)用服務(wù)（因?yàn)椴话魏螛I(yè)務(wù)邏輯），比如創(chuàng)建限速聚合根，過程大概是這樣：

應(yīng)用服務(wù)接受參數(shù)，然后調(diào)用創(chuàng)建限速聚合根工廠（如SpeedLimitFactory），或者通過構(gòu)造函數(shù)創(chuàng)建（包含業(yè)務(wù)規(guī)則，不符合則拋出錯(cuò)誤），當(dāng)然創(chuàng)建還包含聚合根附屬的實(shí)體。

限速聚合根創(chuàng)建好了，調(diào)用倉儲(chǔ)服務(wù)持久化對(duì)象。

返回操作結(jié)果。

那如何改善之前 MQ 中處理的一坨代碼呢？答案就是一行代碼：

＠Testpublic void doSpeedLimitCheckTest（） ｛

System．out．println（＂start．．．．＂）；

speedLimitApplicationService．doSpeedLimitCheck（＂1111＂）；

System．out．println（＂end＂）；

｝

沒錯(cuò)，調(diào)用下應(yīng)用層的doSpeedLimitCheck服務(wù)即可，調(diào)用方完全不需要關(guān)心里面的業(yè)務(wù)邏輯，業(yè)務(wù)隔離。

單元測試執(zhí)行結(jié)果：

結(jié)語

關(guān)于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的分層架構(gòu)：

其實(shí)，我個(gè)人覺得 DDD 的首要核心是確定業(yè)務(wù)的邊界（領(lǐng)域邊界），接著把各個(gè)邊界之間的關(guān)系整理清晰（上下文映射圖），然后再針對(duì)具體的邊界具體設(shè)計(jì)（戰(zhàn)術(shù)設(shè)計(jì)），最后就是工作流程的處理，就像上面圖中所表達(dá)一樣。

好，改造完了，又可以和產(chǎn)品經(jīng)理一起愉快的玩耍了。

作者：岳中新