该如何设计一个购物车系统呢？

随着电子商务的崛起，网站的购物车系统已经成了普遍的功能，近几年Rails快速窜红，但是很多开发者对于设计真正可用的购物车系统仍然感到有很多的困难。

购物车系统第一步

如何设计一个购物车系统呢？在考虑这个问题之前不妨先想想从挑选产品放入购物车，到最后结账的环节中，可以切出哪些功能点方便规划数据库，我们随机可以察觉到有商品和购物车，而以下就是一个初步的案例分析图：

保留金额信息

研判一个购物车可以有多个产品，且一个产品放进多个购物车，而这样的设计图乍看完美却有个问题：试想当一个访客挑选了一样产品，并且放入购物车，这时如果该产品的价钱被后台管理员异动，那么在访客结账之前购物车中的商品价钱也需要异动吗？

如果这是被允许的，那么笔者可以在访客结账的前一秒，将价钱偷改为几百万（之后几年就是官司人生），于是我们需要新的设计避免这样的悲剧：

这样就好了许多，还需额外储存数量与金额信息，这个金额必须是该产品加入购物车当下的数字，如此结账时才不会有价钱异动的争议。

「订单」与「购物车」的差异？

「订单」与「购物车」在电子商务系统中扮演的角色相似却也有些差异，相似是两者都同样会记录访客加入购物车的商品的当前价钱与数量，差异则是「购物车」可编辑商品信息（例如数量或新增商品），但「订单」除了付款之外，不可再异动商品信息，且「订单」会拥有更多如地址、姓名、统编等一类的通信数据。

加上「订单」后的设计图：

付款纪录

「订单」不能变动，唯一可以执行的动作就是「付款」。可是付款未必每次都会成功，且无论成功与否都应该留个记录，记录除了方便管理员查询、找出问题之外，也能提供给使用者供参考与留存。

「交易纪录」不需通信数据，只需要记录成功与否、交易编号即可，以下是新的设计图：

你大概会注意到Trade有个params:text属性，这是用来存放第三方支付服务所回传的数据，可能是JSON或是XML格式，搭配ActiveRecord中的#serialize，可以轻易存取这个字段以供日后的查阅由服务所回传的原始交易数据。

其他人怎么做？

像购物车系统如此常见的功能，想必也有许多开源项目可以使用，其中最有名的三个项目分别是：

ror_ecommerce

Spree

Piggybak

ror_ecommerce

ror-ecommerce

是由David Henner在设计一个电子商务系统时，顺手开源的项目，并且写了一个网站解释他的设计哲学，即便这个项目是三个之中更新最慢的，但对于想学习如何徒手制作电子商务网站的人来说，笔者认为这是最值得参考的学习文件。

ror_ecommerce的数据库设计与本篇文章的示意图、以及「Agile Web Development with Rails 4」书中的示例相同。

Spree

Spree是Rails开源电子商务圈最著名的项目，是由许多资深工程师组成的核心团队所开发，其中不乏Apache软件协会的成员与公司的CTO、CEO，质量保证，加上完整的API、文件以及活络的社群，此外与ActiveMerchant兼容性高，对于单纯只是想要快速架设电子商务网站的人来说，Spree堪称首选。

数据结构方面，有别于前述的构架，Spree并没有Cart entity，而是在Order之中新增一个state属性将「订单」伪装成「购物车」的行为，导致Order的行为逻辑比Cart复杂，但是可以实现的功能更多。

Piggybak

算是Rails开源电子商务的后起之秀，没有Spree那样完备，但其模块化的弹性使得许多开发者也开始投向Piggybak的怀抱，这层关系有点像Paperclip与CarrierWave之间一样，后者也是以模块化著称。

你可以在Rails中任何一个ActiveRecord model中挂上acts_as_sellable使其成为可以买卖的商品，相当简便，如果你想要的是在既有的网站上加上购物功能，而非重新打造一个购物网站，也许这是让你选择Piggybak而非Spree的诱因。

结语

购物车系统没有什么「必须」的设计，不管是什么构架的购物车，可以结账的就是好的购物车。如果对于设计购物车仍有疑惑，也建议不妨多看看他人的开源项目怎么设计，其实许多书中找不到的答案，都放在代码里面，而优良的代码更是可以阅读的。