1

寻找对基于订阅为不同用户启用不同功能集的应用程序的架构模式的一些见解。

我指的不是角色——管理员、用户和经理——而是我的整个可用功能集或容量如何根据我的订阅而改变。

以 github 或freshbooks 或firebase 或heroku 为例。有多个计划。免费计划 A 只能做 X+Y，而付费计划 B 可以做 X+Y+Z（还有 10 个以上），付费计划 C 可以做 W+X+Y+Z（各有 100 个） .

显然，我不想将这些限制和功能过于紧密地融入代码中，否则构建需要很长时间，并且任何更改（在计划之间移动功能，或对各种功能的限制）都会成为一场噩梦。

人们使用什么模式以便用户：

  • 只能使用与他/她相关的那些功能
  • 受到他/她可用的限制的限制
  • 当订阅级别更改（向上或向下）时，这些限制/功能是否会自动更改
  • 看到追加销售机会（显示的功能不可用，但可以购买）？

在这里寻找架构设计，欢迎使用 Java、NodeJS、RoR 或 PHP 的示例。

4

1 回答 1

1

从非常高级的角度来看，我可能会从以下内容开始：

  1. 使“角色”（或任何你想称呼它们的东西）具有包容性 - 不是排他性的。或加法而不是减法。只显示 a/b/c 比默认显示全部更容易，然后尝试锁定受限功能。

  2. 让 API 处理谁可以做什么的所有逻辑，因此当数据到达您的视图时，它已经是基于用户可用功能的有限集合。

  3. 访问级别可以基于每个用户，也可以按某种命名组，这可能更容易批量升级用户等。

  4. 对于原型，您可能会执行 UX，以便如果用户从他们无权访问的 API 请求功能，API 可以发送回某个 HTTP 标头/等。并且您的前端可能会显示一条通用的“升级您的帐户”消息。

你的问题很广泛。

最后一个想法 - 如果您认为应用程序会很大，那么创建一个基本 API 以及从该 API 继承的其他 API 可能会有所帮助，每个 API 都具有特定的功能。同样，有很多方法可以做到这一点......节点模块浮现在脑海中。这样，您可以为用户所在的每个“计划”级别创建不同的体验，但仍然可以重用代码。

于 2013-07-18T18:45:58.940 回答