不就是個短信驗證嘛，還真挺復雜的
支撐子域是為了項目成功必須要處理的問題，但由于沒有現(xiàn)成、成熟的解決方案，必須要定制，費時費力。
如果能恰當?shù)刈R別支撐子域的邊界，形成"可復用"的"解決方案"，就可以將其從支撐子域簡化為通用子域，降低成本和風險 。
不就是個短信驗證嘛，有這么復雜嗎?
前幾天安全專家馬偉發(fā)布了《不就是個短信登錄API嘛，有這么復雜嗎?》，文章從“新增手機號和短信驗證碼登錄”簡單的一句話需求最終演變?yōu)楣适驴?274。
作為用戶，我可以通過手機號和短信驗證碼登錄，以便于我更方便的登錄。
安全驗收標準：
- 短信驗證碼有效期2分鐘
- 驗證碼為6位純數(shù)字
- 每個手機號60秒內(nèi)只能發(fā)送一次短信驗證碼，且這一規(guī)則的校驗必須在服務器端執(zhí)行
- 同一個手機號在同一時間內(nèi)可以有多個有效的短信驗證碼
- 保存于服務器端的驗證碼，至多可被使用3次(無論和請求中的驗證碼是否匹配)，隨后立即作廢，以防止暴力攻擊
- 短信驗證碼不可直接記錄到日志文件
- 發(fā)送短信驗證碼之前，先驗證圖形驗證碼是否正確(可選)
- 集成第三方API做登錄保護(可選)
實際上，根據(jù)我的經(jīng)驗，還可以再加一些驗收條件
- 應該可以通過配置白名單的方式，只向特定手機號碼發(fā)送驗證碼，以免在非生產(chǎn)環(huán)境測試時發(fā)生打擾真實用戶的事故
- 應該可以通過配置By Pass的方式，在特定環(huán)境禁用短信驗證碼發(fā)送，并總是驗證通過，以便在非生產(chǎn)環(huán)境節(jié)約短信配額
一個小小的需求可以衍生出如此之多的驗收條件，而且其中不少是非功能性的(不容易識別的、不容易實現(xiàn)的)，以至于有同學感嘆：
| 厲害，短信驗證這個事，如果有人做成整套解決方案直接調(diào)用就好了，就像keycloak一樣。 |
運用子域進行戰(zhàn)略設計
那么短信驗證是否能成為"整套解決方案"呢，我們可以使用領域驅(qū)動設計中子域分類的框架來分析：
——《DDD精粹：運用子域進行戰(zhàn)略設計》Vaughn Vernon |
可以發(fā)現(xiàn)：
- 核心子域是沒有必要或者說不應該嘗試開發(fā)“可復用”的"整套解決方案"的，因為"可復用“、”整套解決方案“意味著高度的標準化，也就意味著可以以較低成本復制，就不可能成為核心競爭力。
- 通用子域應該采用，而且往往也能找到“可復用”的"整套解決方案"，以便降低成本和風險。
- 支撐子域則顯得很"雞肋"，由于沒有現(xiàn)成、成熟的解決方案，必須定制，但它又不是項目的核心價值。因此，如果能恰當?shù)刈R別支撐子域的邊界，形成"可復用"的"解決方案"，就可以將其從支撐子域簡化為通用子域，進一步降低成本和風險。
我認為短信驗證就是一個好例子，短信驗證自身沒有獨立的價值，但沒有它，某些重要的功能會缺乏保護。但目前只能找到發(fā)送短信的SDK，而缺乏對于"發(fā)送-驗證"這個相對標準化的問題域的支持。
解決方案的形態(tài)是什么樣的
在微服務的大潮下，如果想要復用短信驗證的能力，最先想到的是開發(fā)一個短信驗證服務，開放API給Consumer驗證手機號碼或是短信登錄，名字我都想好了，叫sms-otp(OPT為one time password縮寫)。
(sms-otp 服務)
如果我是甲方IT部門，可能就這么做了，找到一個軟件集成商實現(xiàn)sms-otp就行了。
作為數(shù)字化轉(zhuǎn)型服務廠商，ThoughtWorks的想法會再進一步，是否還有更通用的方法?
ThoughtWorks可能需要為很多客戶交付短信驗證服務，并且出于專業(yè)要求，我們并不會把為A客戶定制的代碼復制到B家使用，這時候一個開箱即用的微服務是最佳選擇嗎?
如果還有其他的“通用”需求呢?例如支付寶支付、微信登錄呢，微服務的數(shù)量就開始膨脹了。在一些項目中，部分客戶的IT基礎設施比較滯后，這類項目未必適合以微服務啟動。那有沒有更靈活的方案，既可以在單體應用中開箱即用，又可以按需擴展為獨立服務呢?
如果存在不確定性，不妨做個MVP
提到開箱即用，近幾年在Java業(yè)界最火的就是Spring Boot了，Auto Configuration大大提高了新應用搭建的速度，在需要定制時又不失靈活性。我覺得這是把好錘子，來敲兩下看看是不是找對了釘子?
我們針對短信驗證推出了自定義的 Spring Boot Starter，大名。
通過starter，既可以將解決方案"嵌入"單體應用，也可以快速啟動新的微服務。
以下是一個簡單的接入示例，為項目添加Starter：
- compile group: "com.github.hippoom:sms-verification-starter:${latestVersion}"
- # 如果需要使用開箱即用的Redis驗證碼存儲
- compile "org.springframework.data:spring-data-redis:2.1.2.RELEASE"
- # 如果需要使用開箱即用的Aliyun短信服務
- compile("com.aliyun:aliyun-java-sdk-core:4.0.6")
- compile("com.aliyun:aliyun-java-sdk-dysmsapi:1.1.0")
為應用注入配置項：
- # application-{profile}.properties
- # 如果使用開箱即用的Aliyun短信服務
- daming.sms.provider=aliyun
- daming.aliyun.accessKeyId={your key id}
- daming.aliyun.accessKeySecret={your key secret}
- daming.aliyun.sms.signature={your text} # 阿里云短信服務的簽名，可以在控制臺找到，如是中文，請轉(zhuǎn)為Unicode
- daming.aliyun.sms.templateCode={your code} #阿里云短信服務的模板Code，可以在控制臺找到
- # 設置私鑰地址，此私鑰會用來簽名被驗證過的手機號碼
- daming.jwt.privateKeyFileLocation=/home/your-app/sms-verification-private.der
啟動應用，并請求驗證碼：
- >curl -H 'Content-Type:
- application/json'
- -XPOST ${host}:${port}/api/sms/verification/code
- -d '{"mobile": "${your mobile}"}'
在收到驗證短信后，嘗試驗證：
- >curl -H 'Content-Type: application/json' -XDELETE ${host}:${port}/api/sms/verification/code -d '{"mobile": "${your mobile}","code":"${the code}"}'
- {"token":"{a very long string}"}%
在Response中可以得到一個JWT，前端應用將該JWT提交給Consumer應用，Consumer應用使用私鑰對應的公鑰即可驗證該手機號碼實現(xiàn)業(yè)務目標(如登錄或保存驗證過的手機號碼)。
一些自問自答
如果是Starter的話，如何靈活定制呢?
既然這些Starter都是解決支撐/通用子域的問題，那么其領域規(guī)則、業(yè)務流程是比較固定、不易變化的。需要靈活定制的部分其實是技術(shù)實現(xiàn)，使用端口和適配器架構(gòu)可以將這兩部分隔離開，使用適配器擴展/變更技術(shù)解決方案。舉個例子：
大名的端口和適配器架構(gòu)
各個出口端口(右側(cè)橙色板塊的Port)作為擴展點，定制的Driven Adapter通過Spring注入。
為什么要綁定技術(shù)棧?非Java技術(shù)棧怎么辦?
可以使用該Starter快速搭建一個微服務。。。
有沒有前端的開箱即用方案 ?
還沒有，我不是前端專家，但我猜測前端的開箱即用方案可以做成類似于 Ant Design 或 Element UI 但更專用的組件?
總結(jié)
- 支撐子域是為了項目成功必須要處理的問題，但由于沒有現(xiàn)成、成熟的解決方案，它必須定制，費時費力
- 如果能恰當?shù)刈R別支撐子域的邊界，形成"可復用"的"解決方案"，就可以將其從支撐子域簡化為通用子域，降低成本和風險
- 短信驗證是從支撐子域簡化為通用子域的好例子，Project Daming(中文為大名)，是我們推出的短信驗證的解決方案，它的目標是將短信驗證從支撐域簡化為通用域，它以自定義的 spring boot starter出現(xiàn)，可以幫助團隊在單體應用中快速嵌入短信驗證功能，也可以快速啟動一個短信驗證的微服務
