功能背景

一点碎碎念

我们做游戏的嘛，多少是需要通过氪金来赚钱的。
目前非买断制的手游，主要获利途径无非就是抽卡、商城售卖道具、各类月卡和广告。
月卡，或者说VIP，作为帐号服务的一种，也可被抽象作为一种商品进行售卖。
抽卡这一行为则由于相关限制，也需要先进行游戏内代币的换取，无法直接进行付费。
换而言之，在我的设计中，商城将会是整个游戏中最重要的部分之一，它会直接关系到收入。

这套商城系统，是我在大学时期（实习，实习也算大学时期嘛）设计完成的，它已经在线上运行了很久。作为全服务器模块中泛用性最强的模块之一，它几乎完美地应对了所有后续提出的需求并不需进行大规模重构。
最初我对此十分得意，但随着服务器功能的不断追加与版本迭代，我发现最初的设计似乎并不能应对接下来的全部需求。即便后续的需求在并没有因为早期设计而受到限制，但这也引起了我的反思。

模块需求

设计初期，策划方面并没有提出十分明确的功能需求，如果有的话那就是“它得是一个商城”。
由于并不像传统互联网公司的结构一样，我们没有明确的业务与产品区分，很多时候需要程序自己去对需求进行完善和判读。这给工作流程带来了一定的麻烦，因为许多需求是陆续被提出的，并非在最初就能够被确定下来。
这也对开发人员提出了一定的要求，如果开发者并不是真正的游戏玩家（或并非工作涉及的品类的游戏玩家等等），那么难免在开发过程中遇到频繁的需求变更或追加。

最终我们确认的需求有以下一些：
1.能够进行灵活的扩展，能够支持到13类最多99个具体商城。
2.依赖策划的配置进行展示，可由策划人员越过程序直接进行控制。
3.能够对因策划疏忽产生的错误进行修复。不影响线上玩家数据和功能。
4.服务器端主导，一切相关操作都需由服务器进行合法性校验。
5.玩家的购买记录需要被半永久性保留。

很多时候我们的需求都是这样的，并不十分明确。策划大多数时间只负责提出自己的要求，具体实现的方式、性能指标、接口设计等等都由研发人员自行决定。可以说这给予了我们极大的自由，但也导致了我在上文提及的对开发人员的要求。

设计思路

作为一个老网瘾少年，商城的设计中我大量参考了现有产品的商城模式，对策划的需求进行了一些修改。
当然，讲道理，这是不应该的，但我就是改了，因为我上我是真的行。（当然，这不好）

我们的产品是使用了帧同步与状态同步混合的同步模式。
关于帧同步和状态同步可以简单看一下这篇博文了解: 状态同步与帧同步
这样的模式允许我们在适当的情况下减少服务器压力，把一部分不是那么重要的数据处理交由客户端自行完成，而在涉及到关键操作（譬如商城模块中购买商品等操作）时由服务器处理来保障操作合法、数据安全。
因此，在最初我们就需要对商城中可能出现的功能进行拆解，并确定其运作时的具体同步方式。

那么接下来的问题就很简单了——功能拆分
商城其实就是一个让玩家们购买物品的地方，那么其最基本的功能就是售卖商品。
售卖商品其实包含了两部分，即商品展示、商品出售，同时“出售”也对应着玩家购买这一操作。
为了对商品进行展示，我们不仅仅需要将商品陈列出来，毕竟有时酒香也怕巷子深。因此我们还需要有对商品进行宣传的功能。这里的“宣传”是泛指的，宣传的方式有很多种，具体由策划负责考虑可能出现的方式。
商城中的商品需要更新和补货，已上架的商品也可能会被下架。
你看肯德基不是就经常出奇奇怪怪的新品然后把口碑不错的产品下架吗
综上所属，我们整理出来如下一些功能

展示、购买/出售、宣传、更新/补货、上架、下架

我们可以对其进行再进一步的整理
宣传 可以被认为是某种特殊的 展示
上架 最终需要体现在 展示 中，下架 这一行为亦同
更新/补货 并不能与 展示 合并，因其与 购买/出售 存有一定的联系

最后决定，将全功能分解为 展示、购买/出售、宣传、更新/补货 四个部分进行编码
接下来就是考虑具体的接口定义、功能逻辑和数据库设计了。
我听说有的公司，这些工作会交给三个人负责，我很酸
今日份的鱼摸完了，下次摸鱼继续写剩下的。
或许找空补一些图会比较易读易理解