不就是个短信验证嘛，有这么复杂吗？
在《不就是个短信登录API嘛，有这么复杂吗？》一文中，“新增手机号和短信验证码登录”简单的一句话需求最终演变为
故事卡-274
作为用户，我可以通过手机号和短信验证码登录，以便于更方便的登录。
安全验收标准:
- 短信验证码有效期2分钟
- 验证码为6位纯数字
- 每个手机号60秒内只能发送一次短信验证码，且这一规则的校验必须在服务器端执行
- 同一个手机号在同一时间内可以有多个有效的短信验证码
- 保存于服务器端的验证码，至多可被使用3次（无论和请求中的验证码是否匹配），随后立即作废，以防止暴力攻击
- 短信验证码不可直接记录到日志文件
7.（可选）发送短信验证码之前，先验证图形验证码是否正确
8.（可选）集成第三方API做登录保护
实际上，根据我的经验，还可以再加一些验收条件
- 应该可以通过配置白名单的方式，只向特定手机号码发送验证码，以免在非生产环境测试时发生打扰真实用户的事故
- 应该可以通过配置By Pass的方式，在特定环境禁用短信验证码发送，并总是验证通过，以便在非生产环境节约短信配额 一个小小的需求可以衍生出如此之多的验收条件，而且其中不少是非功能性的（不容易识别的、不容易实现的），以至于有同学感叹：
厉害，短信验证这个事，如果有人做成整套解决方案直接调用就好了，就像keycloak一样。
那么短信验证是否能成为”整套解决方案”呢，我们可以使用领域驱动设计中子域分类的框架来分析：
核心子域：它是一个唯一的、定义明确的领域模型，你要在这里进行战略投资，并在一个明确的限界上下文中投入大量资源去精心打磨通用语言。它是组织中最重要的项目，因为这将是你与其他竞争者的区别所在。正是因为你的组织无法在所有领域都出类拔萃，所以你必须把核心域打造成组织的核心竞争力。做出这样的决定需要对核心域进行深入地学习与理解，而这需要承诺、协作与试验。这是组织最需要在软件中倾斜其投资的方向。
支撑子域：这类建模方式提倡的是“定制开发”，因为找不到现成的解决方案。你对它的投入无论如何也达不到与核心域相同的程度。你也许会考虑使用外包的方式实现此类限界上下文，以避免因错误的认为其具有战略意义而进行巨额的投资。这类软件模型仍旧非常重要，核心域的成功离不开它。
通用子域：通用子域的解决方案可以采购现成的，也可以采用外包的方式，亦或是由内部团队实现，但我们不用为其分配与核心域同样优质的研发资源，甚至都不如支撑子域。请注意不要把通用子域误认为是核心域。你并不希望对其投资过甚。当讨论一个正在实施DDD的项目时，我们最有可能讨论的是核心域。
——《DDD精粹：运用子域进行战略设计》Vaughn Vernon
可以发现：
- 核心子域是没有必要或者说不应该尝试开发“可复用”的”整套解决方案”的，因为”可复用“、”整套解决方案“意味着高度的标准化，也就意味着可以以较低成本复制，就不可能成为核心竞争力。
- 通用子域应该采用，而且往往也能找到“可复用”的”整套解决方案”，以便降低成本和风险。
- 支撑子域则显得很”鸡肋”，由于没有现成、成熟的解决方案，必须定制，但它又不是项目的核心价值。因此，如果能恰当地识别支撑子域的边界，形成”可复用”的”解决方案”，就可以将其从支撑子域简化为通用子域，进一步降低成本和风险。
我认为短信验证就是一个好例子，短信验证自身没有独立的价值，但没有它，某些重要的功能会缺乏保护。但目前只能找到发送短信的SDK，而缺乏对于”发送-验证”这个相对标准化的问题域的支持。
在微服务的大潮下，如果想要复用短信验证的能力，最先想到的是开发一个短信验证服务，开放API给Consumer验证手机号码或是短信登录，名字我都想好了，叫sms-otp（OPT为one time password缩写）。
（sms-otp 服务）
但是，如果我们的假设成立，我们还会找到其他支撑域通用化的点子，例如支付宝支付、微信登录等，微服务的数量就开始膨胀了。如果基础设施或是人员技能还没有准备好，未必适合以微服务启动。因此，我们尝试找到一种既可以嵌入遗留单体系统，又可以快速启动微服务的解决方案形式，而spring-boot-starter正好符合我们的需要。
计算机科学中最难的两个问题，一个是分布式系统中的缓存系统，另一个则是起名字。
为了避免第二个问题，我们决定以各个城市的著名景点周边道路作为项目代号。
Daming，是上海市大名路的简称，位于外滩附近