不就是个短信验证嘛,还真挺复杂的
副标题[/!--empirenews.page--]
支撑子域是为了项目成功必须要处理的问题,但由于没有现成、成熟的解决方案,必须要定制,费时费力。 如果能恰当地识别支撑子域的边界,形成"可复用"的"解决方案",就可以将其从支撑子域简化为通用子域,降低成本和风险 。 不就是个短信验证嘛,有这么复杂吗? 前几天安全专家马伟发布了《不就是个短信登录API嘛,有这么复杂吗?》,文章从“新增手机号和短信验证码登录”简单的一句话需求最终演变为故事卡-274。 作为用户,我可以通过手机号和短信验证码登录,以便于我更方便的登录。 安全验收标准:
实际上,根据我的经验,还可以再加一些验收条件
一个小小的需求可以衍生出如此之多的验收条件,而且其中不少是非功能性的(不容易识别的、不容易实现的),以至于有同学感叹: 运用子域进行战略设计 那么短信验证是否能成为"整套解决方案"呢,我们可以使用领域驱动设计中子域分类的框架来分析: 可以发现:
我认为短信验证就是一个好例子,短信验证自身没有独立的价值,但没有它,某些重要的功能会缺乏保护。但目前只能找到发送短信的SDK,而缺乏对于"发送-验证"这个相对标准化的问题域的支持。 解决方案的形态是什么样的 在微服务的大潮下,如果想要复用短信验证的能力,最先想到的是开发一个短信验证服务,开放API给Consumer验证手机号码或是短信登录,名字我都想好了,叫sms-otp(OPT为one time password缩写)。 (sms-otp 服务) 如果我是甲方IT部门,可能就这么做了,找到一个软件集成商实现sms-otp就行了。 作为数字化转型服务厂商,ThoughtWorks的想法会再进一步,是否还有更通用的方法? ThoughtWorks可能需要为很多客户交付短信验证服务,并且出于专业要求,我们并不会把为A客户定制的代码复制到B家使用,这时候一个开箱即用的微服务是最佳选择吗? 如果还有其他的“通用”需求呢?例如支付宝支付、微信登录呢,微服务的数量就开始膨胀了。在一些项目中,部分客户的IT基础设施比较滞后,这类项目未必适合以微服务启动。那有没有更灵活的方案,既可以在单体应用中开箱即用,又可以按需扩展为独立服务呢? 如果存在不确定性,不妨做个MVP 提到开箱即用,近几年在Java业界最火的就是Spring Boot了,Auto Configuration大大提高了新应用搭建的速度,在需要定制时又不失灵活性。我觉得这是把好锤子,来敲两下看看是不是找对了钉子? 我们针对短信验证推出了自定义的 Spring Boot Starter,大名。 通过starter,既可以将解决方案"嵌入"单体应用,也可以快速启动新的微服务。 以下是一个简单的接入示例,为项目添加Starter:
为应用注入配置项:
(编辑:广西网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |