SIMBOSS：物聯(lián)網(wǎng)業(yè)務如何應用領域驅動設計

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

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

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

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

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

腳本式的開發(fā)

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

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

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

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

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

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

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

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

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

SpeedLimitController．java：接受前端傳遞參數(shù)，并調(diào)用 Service，封裝返回數(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ù)維護好了，接下來要進行限速檢查了，我們目前的實現(xiàn)方式是：有一個定時任務，每間隔一段時間批量執(zhí)行，查詢所有的限速配置（上面的speed＿limit），然后根據(jù)用戶 ID 和套餐 ID，查詢出符合條件的物聯(lián)網(wǎng)卡，然后將卡號丟到 MQ 中異步處理，MQ 接受到卡號，再查詢對應的限速配置（speed＿limit以及speed＿limit＿config），然后再查詢此卡的套餐使用量，最后根據(jù)規(guī)則匹配，進行限速設置等操作。

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

為什么代碼不貼出來？因為里面的代碼慘不忍睹啊，if．．else．．的各種嵌套，所以，還是眼不看為凈。

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

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

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

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

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

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

領域驅動設計

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

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

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

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

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

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

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

SpeedLimitLevel實體：其實限速級別應該設計成值對象，因為它并沒有生命周期和唯一標識的概念，只是一個具體的值。

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

SpeedLimitService領域服務：因為涉及到多個上下文的協(xié)調(diào)和交互，限速聚合根并不能獨立完成，所以這些聚合根完成不了的操作，可以放到領域服務中去處理。

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

以上因為不好在現(xiàn)有項目中做改造，我就用 Spring Boot 做了一個項目示例（Spring Boot 用起來真的很爽，簡潔高效，做微服務非常好），大致的項目結構：

├── 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．＊；／／實體import com．qipeng．simboss．speedlimit．domain．valobj．＊；／／值對象import com．qipeng．simboss．speedlimit．domain．service．＊；／／領域服務import com．qipeng．simboss．speedlimit．domain．repo．repository．＊；／／倉儲import com．qipeng．simboss．speedlimit．repo．dao．＊；／／mapper接口import com．qipeng．simboss．speedlimit．a(chǎn)pplication．service．＊；／／應用層服務

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

／＊＊

＊ 是否刪除當前限速，不持久化

＊／

private Boolean isDel ＝ false；

／＊＊

＊ 卡的限速值，不持久化

＊／

private Double cardSpeedLimit；

／＊＊

＊ 獲取限速值

＊／

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

Boolean isRealnamePassed， Double currentSpeedLimit） ｛

／／todo this．．．

｝

／＊＊

＊ 設置是否刪除當前限速

＊／

private void setIsDelSpeedLimit（Double currentSpeedLimit） ｛

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

／／todo this．．．

｝

｝

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

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

SpeedLimit聚合根中包含configs對象（限速配置集合），因為限速配置實體依附于SpeedLimit聚合根。

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

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

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

好，那我們就看下限速領域服務的具體實現(xiàn)：

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

／＊＊

＊ 限速領域服務

＊／＠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）；

｝

｝

｝

／＊＊

＊ 單個限速檢查

＊／

＠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．．．＂）；

｝

｝

｝

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

通過SpeedLimitCheckContext上下文獲取iccid，然后獲取對應的限速對象和套餐流量對象。

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

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

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

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

好，我們再來看下應用服務中的代碼：

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è)務邏輯，只是工作流程的處理，比如接受參數(shù)，然后調(diào)用相關服務，封裝返回等，如果需要持久化聚合根對象，調(diào)用倉儲服務即可（可能會涉及到 UnitOfWork），另外，像限速聚合根對象的維護，也是實現(xiàn)在應用服務（因為不包含任何業(yè)務邏輯），比如創(chuàng)建限速聚合根，過程大概是這樣：

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

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

返回操作結果。

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

＠Testpublic void doSpeedLimitCheckTest（） ｛

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

speedLimitApplicationService．doSpeedLimitCheck（＂1111＂）；

System．out．println（＂end＂）；

｝

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

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

結語

關于領域驅動設計的分層架構：

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

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

作者：岳中新