万事开头难，要编写一套系统，首先是规划。一个系统做得好不好，很大程度上取决于开始的规划好不好、设计好不好。一个电子商城的后台管理系统，首先要做的应该是帐号管理模块和权限模块。但是，我原先开始写的时候，并没有想到要做得多完善，所以是先写的业务功能模块（会员模块、商品模块、订单模块）。当然我原先写的商品模块，也没有做太多的规划，现在总结出来，自然是要有所规划。
首先，我们分析一下，商品会有哪些基本属性：名称、图片、价格、详情、库存，细分的话，名称可以有主名称、短名称，图片有主图、副图，价格可以分为成本价、售价、原价等等。然后，商品还会有一些状态属性，比如：是否上架，是否逻辑删除，是否开启多规格，是否审核等等。最后就是商品的归类信息，商品属于哪个分类、属于哪个分组等等。把这些确定，商品的模型，也就基本上确定了。当然，后期还会为商品添加更多的属性，这就是属于扩展的东西了。
现在的重点是，在商品的这些属性里，我们需要考虑一下，哪些属性存在扩展性？首先想到的，应该就是库存，如果使用这个系统的公司，规模比较大，可能就会有自己的仓储系统，那么商品的库存就肯定是来源于仓储系统了。或者是别人想在现有商城的基础上，自己开发一个仓储系统，那么库存也肯定是要移到新开发的仓储系统中去。这样一来，我们开发的商品模块就需要考虑怎么样来实现库存的扩展性。要实现库存的扩展性，需要考虑2个问题：
1. 如何确定，用户有没有扩展库存
2. 如果用户有扩展库存系统，要如何去获取库存
第1个问题，好解决，可以在配置文件中设置一个变量，通过这个变量来确定是否有扩展库存。难的是第2个问题，现在系统要先开发，以后，用户会用或是会开发什么样的仓储系统，我根本就没法知道。我希望做到的是，别人把自己的仓储系统整合进来，或是自己开发一个仓储系统，不需要动我已经写好的商品模块的代码。这个时候，就需要用到接口，在系统中定义一个接口，接口中定义了一系列操作库存的方法，然后，别人要整合自己的仓储系统也好，或是自己开发一个仓储系统也好，就必须要提供一个类实现这个接口，然后把类名写到配置文件中。类名有了，方法名也有了（接口中定义），要调用方法，不就简单了吗！再把两个问题综合起来考虑，实际上第2个问题解决了，第1个问题也就不存在了，只需要判断用户有没有提供类名，就可以知道用户有没有使用扩展库存了。再接下来，要考虑的就是，判断类名是否为空的时机。
可以在系统启动的时候判断一次，之后就不再判断了。这样做的好处是，性能高，不好的地方是，不支持热加载，也就是别人把一个仓储系统整合进来了，改了配置，需要重启一下系统，才可以生效。另一种做法就是，系统启动的时候不判断，在每次调用操作库存的方法时，再判断。这种做法，和前面的就相反了，因为每次操作库存都要判断，耗性能，但好处是，可以热加载。那么，我两种方法的优点都想要，但不想要他们的缺点，可不可以呢？这个，必须可以！我仍然使用第一种方法，然后在系统中提供一个方法，重新加载配置文件，那么，当更改了配置文件之后，调用一下这个方法，就可以让更改的配置生效了。
再接下来要考虑的就是，商品的一些促销功能的扩展了。比如：用户可以在已有商城的基础上，添加团购的功能。同样的，我也希望用户添加团购功能，不需要动我的源代码。这个，又要怎样设计？实际上，还是在库存上做文章。用户要做一个团购或是其它的促销模块，都只是在已有的商品模块中，划拨出去一部分库存，划拨出去的库存，就跟主系统的商品模块不搭界了。比如一个商品有100个库存，在这100个库存中，分出20个来做团购。那么分出来的20个库存，就只在团购模块可以操作，主系统能操作的库存就只有80个了。这就好比中央财政给地方拨款一样的，款拨给你了，就跟中央不搭界了，你地方要怎么用，中央也完全不管。就这么简单吗？当然不是！作为一名合格的商人，最重要的是什么？会算帐。作为一个优秀的电子商城，最重要的就是统计功能了。拿月统计来说，一个月下来，进了多少货，卖了多少货，仓库里还有多少货？这些都必须要有统计的。团购功能划去了一部分库存，跟主系统不搭界了，主系统不能操作，但有些信息还是得给主系统的，就像地方要给中央汇报一样。划分过去的库存，卖了多少，还剩多少，在主系统进行统计的时候，得提供这些数据。所以，这些扩展模块，也要实现定义的接口。这些接口，定义的方法主要是获取扩展功能的库存使用情况，还有交易额的统计信息，交易额的接口定义，是属于订单模块的，就不是在商品模块定义了。
至于其它的属性是否有扩展，这个就要看各个公司的具体业务和发展走向了。