不就是個短信驗證嘛，有這么復雜嗎？

前幾天安全專家馬偉發(fā)布了《不就是個短信登錄API嘛，有這么復雜嗎？》，文章從“新增手機號和短信驗證碼登錄”簡單的一句話需求最終演變?yōu)?/p>

實際上，根據我的經驗，還可以再加一些驗收條件

• 應該可以通過配置白名單的方式，只向特定手機號碼發(fā)送驗證碼，以免在非生產環(huán)境測試時發(fā)生打擾真實用戶的事故

• 應該可以通過配置By Pass的方式，在特定環(huán)境禁用短信驗證碼發(fā)送，并總是驗證通過，以便在非生產環(huán)境節(jié)約短信配額

一個小小的需求可以衍生出如此之多的驗收條件，而且其中不少是非功能性的（不容易識別的、不容易實現的），以至于有同學感嘆：

運用子域進行戰(zhàn)略設計

那么短信驗證是否能成為'整套解決方案'呢，我們可以使用領域驅動設計中子域分類的框架來分析：

可以發(fā)現：

1. 核心子域是沒有必要或者說不應該嘗試開發(fā)“可復用”的'整套解決方案'的，因為'可復用“、”整套解決方案“意味著高度的標準化，也就意味著可以以較低成本復制，就不可能成為核心競爭力。

2. 通用子域應該采用，而且往往也能找到“可復用”的'整套解決方案'，以便降低成本和風險。

3. 支撐子域則顯得很'雞肋'，由于沒有現成、成熟的解決方案，必須定制，但它又不是項目的核心價值。因此，如果能恰當地識別支撐子域的邊界，形成'可復用'的'解決方案'，就可以將其從支撐子域簡化為通用子域，進一步降低成本和風險。

我認為短信驗證就是一個好例子，短信驗證自身沒有獨立的價值，但沒有它，某些重要的功能會缺乏保護。但目前只能找到發(fā)送短信的SDK，而缺乏對于'發(fā)送-驗證'這個相對標準化的問題域的支持。

解決方案的形態(tài)是什么樣的

在微服務的大潮下，如果想要復用短信驗證的能力，最先想到的是開發(fā)一個短信驗證服務，開放API給Consumer驗證手機號碼或是短信登錄，名字我都想好了，叫sms-otp（OPT為one time password縮寫）。

（sms-otp 服務）

如果我是甲方IT部門，可能就這么做了，找到一個軟件集成商實現sms-otp就行了。

作為數字化轉型服務廠商，ThoughtWorks的想法會再進一步，是否還有更通用的方法？

ThoughtWorks可能需要為很多客戶交付短信驗證服務，并且出于專業(yè)要求，我們并不會把為A客戶定制的代碼復制到B家使用，這時候一個開箱即用的微服務是最佳選擇嗎？

如果還有其他的“通用”需求呢？例如支付寶支付、微信登錄呢，微服務的數量就開始膨脹了。在一些項目中，部分客戶的IT基礎設施比較滯后，這類項目未必適合以微服務啟動。那有沒有更靈活的方案，既可以在單體應用中開箱即用，又可以按需擴展為獨立服務呢？

如果存在不確定性，不妨做個MVP

提到開箱即用，近幾年在Java業(yè)界最火的就是Spring Boot了，Auto Configuration大大提高了新應用搭建的速度，在需要定制時又不失靈活性。我覺得這是把好錘子，來敲兩下看看是不是找對了釘子？

通過starter，既可以將解決方案'嵌入'單體應用，也可以快速啟動新的微服務。

以下是一個簡單的接入示例，為項目添加Starter:

為應用注入配置項：

# 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} # 阿里云短信服務的簽名，可以在控制臺找到，如是中文，請轉為Unicode
daming.aliyun.sms.templateCode={your code} #阿里云短信服務的模板Code，可以在控制臺找到
# 設置私鑰地址，此私鑰會用來簽名被驗證過的手機號碼
daming.jwt.privateKeyFileLocation=/home/your-app/sms-verification-private.der

啟動應用，并請求驗證碼：

在收到驗證短信后，嘗試驗證：

>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應用使用私鑰對應的公鑰即可驗證該手機號碼實現業(yè)務目標（如登錄或保存驗證過的手機號碼）。

一些自問自答

既然這些Starter都是解決支撐/通用子域的問題，那么其領域規(guī)則、業(yè)務流程是比較固定、不易變化的。需要靈活定制的部分其實是技術實現，使用端口和適配器架構可以將這兩部分隔離開，使用適配器擴展/變更技術解決方案。舉個例子：

各個出口端口（右側橙色板塊的Port）作為擴展點，定制的Driven Adapter通過Spring注入。

可以使用該Starter快速搭建一個微服務。。。

還沒有，我不是前端專家，但我猜測前端的開箱即用方案可以做成類似于 Ant Design 或 Element UI 但更專用的組件？

總結

1. 支撐子域是為了項目成功必須要處理的問題，但由于沒有現成、成熟的解決方案，它必須定制，費時費力

2. 如果能恰當地識別支撐子域的邊界，形成'可復用'的'解決方案'，就可以將其從支撐子域簡化為通用子域，降低成本和風險

3. 短信驗證是從支撐子域簡化為通用子域的好例子，Project Daming（中文為大名），是我們推出的短信驗證的解決方案，它的目標是將短信驗證從支撐域簡化為通用域，它以自定義的 spring boot starter出現，可以幫助團隊在單體應用中快速嵌入短信驗證功能，也可以快速啟動一個短信驗證的微服務

花絮

計算機科學中最難的兩個問題，一個是分布式系統中的緩存系統，另一個則是起名字，為了避免第二個問題，我們決定以各個城市的著名景點周邊道路作為項目代號。

• 大名，是上海市大名路的簡稱，位于外灘附近