萬事開頭難，要編寫一套系統，首先是規劃。一個系統做得好不好，很大程度上取決於開始的規劃好不好、設計好不好。一個電子商城的後臺管理系統，首先要做的應該是帳號管理模組和許可權模組。但是，我原先開始寫的時候，並沒有想到要做得多完善，所以是先寫的業務功能模組（會員模組、商品模組、訂單模組）。當然我原先寫的商品模組，也沒有做太多的規劃，現在總結出來，自然是要有所規劃。

首先，我們分析一下，商品會有哪些基本屬性：名稱、圖片、價格、詳情、庫存，細分的話，名稱可以有主名稱、短名稱，圖片有主圖、副圖，價格可以分為成本價、售價、原價等等。然後，商品還會有一些狀態屬性，比如：是否上架，是否邏輯刪除，是否開啟多規格，是否稽核等等。最後就是商品的歸類資訊，商品屬於哪個分類、屬於哪個分組等等。把這些確定，商品的模型，也就基本上確定了。當然，後期還會為商品新增更多的屬性，這就是屬於擴充套件的東西了。

現在的重點是，在商品的這些屬性裡，我們需要考慮一下，哪些屬性存在擴充套件性？首先想到的，應該就是庫存，如果使用這個系統的公司，規模比較大，可能就會有自己的倉儲系統，那麼商品的庫存就肯定是來源於倉儲系統了。或者是別人想在現有商城的基礎上，自己開發一個倉儲系統，那麼庫存也肯定是要移到新開發的倉儲系統中去。這樣一來，我們開發的商品模組就需要考慮怎麼樣來實現庫存的擴充套件性。要實現庫存的擴充套件性，需要考慮2個問題：

1. 如何確定，使用者有沒有擴充套件庫存

2. 如果使用者有擴充套件庫存系統，要如何去獲取庫存

第1個問題，好解決，可以在配置檔案中設定一個變數，通過這個變數來確定是否有擴充套件庫存。難的是第2個問題，現在系統要先開發，以後，使用者會用或是會開發什麼樣的倉儲系統，我根本就沒法知道。我希望做到的是，別人把自己的倉儲系統整合進來，或是自己開發一個倉儲系統，不需要動我已經寫好的商品模組的程式碼。這個時候，就需要用到介面，在系統中定義一個介面，介面中定義了一系列操作庫存的方法，然後，別人要整合自己的倉儲系統也好，或是自己開發一個倉儲系統也好，就必須要提供一個類實現這個介面，然後把類名寫到配置檔案中。類名有了，方法名也有了（介面中定義），要呼叫方法，不就簡單了嗎！再把兩個問題綜合起來考慮，實際上第2個問題解決了，第1個問題也就不存在了，只需要判斷使用者有沒有提供類名，就可以知道使用者有沒有使用擴充套件庫存了。再接下來，要考慮的就是，判斷類名是否為空的時機。

可以在系統啟動的時候判斷一次，之後就不再判斷了。這樣做的好處是，效能高，不好的地方是，不支援熱載入，也就是別人把一個倉儲系統整合進來了，改了配置，需要重啟一下系統，才可以生效。另一種做法就是，系統啟動的時候不判斷，在每次呼叫操作庫存的方法時，再判斷。這種做法，和前面的就相反了，因為每次操作庫存都要判斷，耗效能，但好處是，可以熱載入。那麼，我兩種方法的優點都想要，但不想要他們的缺點，可不可以呢？這個，必須可以！我仍然使用第一種方法，然後在系統中提供一個方法，重新載入配置檔案，那麼，當更改了配置檔案之後，呼叫一下這個方法，就可以讓更改的配置生效了。

再接下來要考慮的就是，商品的一些促銷功能的擴充套件了。比如：使用者可以在已有商城的基礎上，新增團購的功能。同樣的，我也希望使用者新增團購功能，不需要動我的原始碼。這個，又要怎樣設計？實際上，還是在庫存上做文章。使用者要做一個團購或是其它的促銷模組，都只是在已有的商品模組中，劃撥出去一部分庫存，劃撥出去的庫存，就跟主系統的商品模組不搭界了。比如一個商品有100個庫存，在這100個庫存中，分出20個來做團購。那麼分出來的20個庫存，就只在團購模組可以操作，主系統能操作的庫存就只有80個了。這就好比中央財政給地方撥款一樣的，款撥給你了，就跟中央不搭界了，你地方要怎麼用，中央也完全不管。就這麼簡單嗎？當然不是！作為一名合格的商人，最重要的是什麼？會算帳。作為一個優秀的電子商城，最重要的就是統計功能了。拿月統計來說，一個月下來，進了多少貨，賣了多少貨，倉庫裡還有多少貨？這些都必須要有統計的。團購功能劃去了一部分庫存，跟主系統不搭界了，主系統不能操作，但有些資訊還是得給主系統的，就像地方要給中央彙報一樣。劃分過去的庫存，賣了多少，還剩多少，在主系統進行統計的時候，得提供這些資料。所以，這些擴充套件模組，也要實現定義的介面。這些介面，定義的方法主要是獲取擴充套件功能的庫存使用情況，還有交易額的統計資訊，交易額的介面定義，是屬於訂單模組的，就不是在商品模組定義了。

至於其它的屬性是否有擴充套件，這個就要看各個公司的具體業務和發展走向了。