我开始研究关于Public API的良好实践，特别是关于如何处理中断的更改。有很多技术细节与版本控制(或非版本控制！(有关，但我更感兴趣的是代码库含义。
想象一个基本场景，您有一个业务规则"密码必须至少有10个字符"。您在公共API中公开了一个"创建用户"场景，接受密码。
您有数百个客户端在使用它，有一天，您决定将业务规则更改为"密码必须至少有15个字符"。即使你没有改变API签名和有效载荷的语义，你只是在API中引入了一个突破性的改变，因为你改变了这个API的行为。
你会怎么处理？
我只发现错误的方法：
- 用过时/版本化的不变量修改域不变量(业务规则(：这将在代码可读性/测试等方面造成噩梦
- 每个API版本重复您的代码库：这将造成维护噩梦
- 希望有一天你能摒弃这一切，重新变得干净：在你的梦中
在你的工作中有过这样的真实生活经历吗？
最简单的方法就是与客户沟通，并在几周/几个月前警告他们即将发生的更改。通过这种方式，他们可以为突破性的变化做好准备。
如果您绝对必须支持旧客户端，另一种选择是将域保持不变为10，但为创建用户场景添加一个额外的api调用，该调用会检查密码长度并验证其在域外的长度为15。然后，鼓励用户迁移到新的CreateUser端点。这适用于像这样的简单情况，但对于复杂的不变量，或者如果您的域在不同的上下文中使用(多个Api、桌面应用程序等(，这将变得非常困难。
如果你决定采用这种方法，一个好的建议是确保你有指标来知道有多少客户端使用旧端点，有多少客户端在使用新端点。当你达到某个阈值时，你可以关闭旧的端点，并将最小密码长度15不变量从Api移动到域，