概述

---

在日常开发中，有时候你的上司会跟你说，这个模块的设计扩展性要高。把这句话说出来很简单，但是要做到则非常难。导致难的其中一个因素是：

你不熟悉这个行业的业务的玩法

我举个例子来说明。像电商行业里的满多少减多少这样的营销活动，如果你一开始只是认为这种活动就是单指满多少钱减多少钱的话(例如：满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里。

---

小结

---

从上面的例子可以总结出几个小的体会：

• 当你从产品经理那里拿到需求后，在做代码设计前，可以先问他，这个模块后面会怎么发展，提前了解一些将来可能要做的业务；
• 自己参与某个模块开发的时候，如果业界也有类似的东西，最好也去了解一下，大家都是怎么玩的；
• 你的设计不具备扩展性，导致后续改动起来难，也不要灰心气馁，因为有些情况下真的很难做到设计扩展性强。

---

原文链接

---

设计要做到扩展性强还挺难的