业务功能设计时关于扩展性和最小功能原则的思考

最近遇到一个迷惑，产品的需求是已配货，已发货，已签收的订单可以售后退款，在实现接口的时候，我做了check，只能是已配货，已发货，已签收的才能退款，后来又在思考，这样写死，shib是不是没有扩展性，虽然符合了最小功能设计了，但是有一天产品说，配货中的也能退货，是不是就是需求修改代码，扩展性就不好了？是不是把这个可以退货的状态放在字典里面。

找我们架构师说了这事，架构给出的是：这个变化的概率有多大，不要过度设计，加入真的出现这样的修改，确定这个概率增大，你下次再把它做到zidi字典表才是对的

对于这种很明确的需求，在不确定修改的概率情况下，不需要过于考虑扩展性；对于不太确定的需求，比如：京东说大客户账户余额明细返回的416可以认为是退款成功，这个是外部系统的东西，可能会变化，可以做到字典表，方便京东业务tiao调整，我们及时跟上