不就是个短信验证嘛，还真挺复杂的

启动应用，并请求验证码：

>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应用使用私钥对应的公钥即可验证该手机号码实现业务目标(如登录或保存验证过的手机号码)。

一些自问自答

如果是Starter的话，如何灵活定制呢?

既然这些Starter都是解决支撑/通用子域的问题，那么其领域规则、业务流程是比较固定、不易变化的。需要灵活定制的部分其实是技术实现，使用端口和适配器架构可以将这两部分隔离开，使用适配器扩展/变更技术解决方案。举个例子：

大名的端口和适配器架构

各个出口端口(右侧橙色板块的Port)作为扩展点，定制的Driven Adapter通过Spring注入。

为什么要绑定技术栈?非Java技术栈怎么办?

可以使用该Starter快速搭建一个微服务。。。

有没有前端的开箱即用方案 ?

还没有，我不是前端专家，但我猜测前端的开箱即用方案可以做成类似于 Ant Design 或 Element UI 但更专用的组件?

总结

• 支撑子域是为了项目成功必须要处理的问题，但由于没有现成、成熟的解决方案，它必须定制，费时费力
• 如果能恰当地识别支撑子域的边界，形成"可复用"的"解决方案"，就可以将其从支撑子域简化为通用子域，降低成本和风险
• 短信验证是从支撑子域简化为通用子域的好例子，Project Daming(中文为大名)，是我们推出的短信验证的解决方案，它的目标是将短信验证从支撑域简化为通用域，它以自定义的 spring boot starter出现，可以帮助团队在单体应用中快速嵌入短信验证功能，也可以快速启动一个短信验证的微服务

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!