这个模块可以做成一个子系统。如果我把这个子系统做得足够通用的话，那以后我可以在其它项目中直接接入，修改几个配置参数即可。一劳永逸，简直不要太爽。
“通用”，这是一个极具诱惑力的名词。它意味着可以避免重复工作，提高未来的效率。如果按这个角度想的话，它是一种资产。在理想的情况下，我们通过不断的累积“通用”资产，来持续提高自己的开发效率，为自己带来优势。
但实际上，“通用”也是一种债务。
为了维持这种“通用性”，我们得理解和考虑更多的使用场景，继而引发出更多的抽象，和更复杂的架构。
作为独立开发者，我们的精力和时间都非常有限，在这种条件下，我们应该把开发目标限制在更精准的使用场景。
经历分享
我想把这个游戏的商城系统设计得更通用些，尽可能的可配置，这样就可以兼容常见的单机模拟经营类游戏了”
这个想法，首要问题是把目标设置太大了。另外的问题是，我们对自己项目以外的使用场景大概率是理解不到位的，所以，很可能会做错误的工作。
在一段时间的苦苦挣扎后，我觉悟了（累了），我都不确定下一个游戏是怎样的，可能我未来的每个游戏都是独一无二的，业务逻辑也是独一无二的。
试想一下，Unity商店各种插件不也是很通用的？也不见得都适用于我的项目。
于是我把目标定为 “适用于本游戏的商城系统，代码结构和接口清晰”。
其实，只要保持代码结构清晰就行。 到下一个项目，万一还是有用到商城系统，但是需求有点变化。没事，把旧的代码拷贝过去，修改一下适配新的功能需求。这就已经很好了。