概述
在日常開發中，有時候你的上司會跟你說，這個模塊的設計擴展性要高。把這句話說出來很簡單，但是要做到則非常難。導致難的其中一個因素是：
你不熟悉這個行業的業務的玩法
我舉個例子來說明。像電商行業裏的滿多少減多少這樣的營銷活動，如果你一開始只是認爲這種活動就是單指滿多少錢減多少錢的話(例如：滿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裏。
小結
從上面的例子可以總結出幾個小的體會：
- 當你從產品經理那裏拿到需求後，在做代碼設計前，可以先問他，這個模塊後面會怎麼發展，提前瞭解一些將來可能要做的業務；
- 自己參與某個模塊開發的時候，如果業界也有類似的東西，最好也去了解一下，大家都是怎麼玩的；
- 你的設計不具備擴展性，導致後續改動起來難，也不要灰心氣餒，因爲有些情況下真的很難做到設計擴展性強。