概述
在日常开发中，有时候你的上司会跟你说，这个模块的设计扩展性要高。把这句话说出来很简单，但是要做到则非常难。导致难的其中一个因素是：
你不熟悉这个行业的业务的玩法
我举个例子来说明。像电商行业里的满多少减多少这样的营销活动，如果你一开始只是认为这种活动就是单指满多少钱减多少钱的话(例如：满100元减20元)，那么就很有可能导致无论你如何设计，它都不具备可扩展性。为什么呢？
由于你只是认为只有类似满100元减20元这样的玩法，就很有可能如下设计表：
CREATE TABLE `manjian_activity` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`activity_name` varchar(100) NOT NULL DEFAULT '' COMMENT '活动名称',
`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '活动状态',
`target_price` int(11) DEFAULT NULL COMMENT '满减，目标金额',
`off_price` int(11) DEFAULT NULL COMMENT '满减，减额'
)
以满100减20为例子，target_price就是100，off_price就是20，我们把这两个钱放置在活动表里了。好了，所有的业务代码都围绕这样的表设计来写代码，也经过测试和上线了。表面看起来一帆风顺的，但是产品经理还会再跟你提需求，说我们要支持如下规则:
- 满100享受5折
- 满100送1件赠品
- 要支持梯度，满100元减20，满200减30
这个时候就傻眼了，manjian_activity表不支持这样的玩法，而之前的所有代码已经围绕这个表设计来展开了。如果要支持新的玩法，改动会很大。这个时候你可能会说，当时的表设计真烂。但是你要知道，设计者当时对满多少减多少这种营销活动的认知是不够的，不知道业界各种各样的玩法，怎么可能会有扩展性强的设计呢。这个不能怪罪开发。
如果一早就知道满减这种营销活动的各种业务玩法，那么我们就知道需要设计一张规则表，来存储规则。像
- 满100享受5折
- 满100送1件赠品
- 要支持梯度，满100元减20，满200减30
这些都是规则。
CREATE TABLE `manjian_rule` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`threshold_value` int(11) NOT NULL DEFAULT '0' COMMENT '门槛值',
`discount_type` int(11) NOT NULL DEFAULT '0' COMMENT '优惠类型0 减钱，1 打折 2 送赠品',
`discount_value` varchar(50) NOT NULL DEFAULT '' COMMENT '优惠值，字符意义由优惠类型决定',
`activity_id` int(11) NOT NULL COMMENT '满减活动id'
PRIMARY KEY (`id`)
)
manjian_rule表就可以满足产品提的新需求了。一个活动对应的所有规则都在manjian_rule里。
小结
从上面的例子可以总结出几个小的体会：
- 当你从产品经理那里拿到需求后，在做代码设计前，可以先问他，这个模块后面会怎么发展，提前了解一些将来可能要做的业务；
- 自己参与某个模块开发的时候，如果业界也有类似的东西，最好也去了解一下，大家都是怎么玩的；
- 你的设计不具备扩展性，导致后续改动起来难，也不要灰心气馁，因为有些情况下真的很难做到设计扩展性强。
原文链接
设计要做到扩展性强还挺难的
