3.3 应用开发中的模型
使用模型思维开发软件并不是计算机科学家的专利，对于应用开发来说我们也会想尽办法找到合适的模型。应用程序设计中有很多套路，一些书叫做范式、模式或者其他词汇，如果按照模型思维的逻辑，我们可以叫它们模型。根据场景找到合适的模型就能把应用程序设计的很好。
做应用程序设计，除了特定领域外，大部分应用都有一些通用的的内在逻辑，我们可以尝试把这些内在的逻辑找出来，通过模型可以帮助分析业务问题。
通俗来说，系统分析的关键是怎么找到一根线把系统的大部分元素串起来，达到逻辑自洽的目的。串的东西越多，能分析的系统就越复杂。现代商业软件系统的类型往往由商业价值决定的，一般有这几类：
电商类。业务的关键逻辑是电商，即使看起来和电商无关。像 Keep、抹茶美妆这类垂领域的 APP 看似是生活类 APP，实际上也是电商应用。对于电商类，订单就是贯穿整个用户操作逻辑，我们可以围绕订单串整个系统。 电商类。业务的关键逻辑是电商，即使看起来和电商无关。像 Keep、抹茶美妆这类垂领域的 APP 看似是生活类 APP，实际上也是电商应用。对于电商类，订单就是贯穿整个用户操作逻辑，我们可以围绕订单串整个系统。
协作工具类。一些项目管理系统，比如禅道、JIRA、Worktitle 等，都属于协作工具类。这些工具类应用中最核心的是工作流，任务的状态和流转是贯穿整个系统的主线。 协作工具类。一些项目管理系统，比如禅道、JIRA、Worktitle 等，都属于协作工具类。这些工具类应用中最核心的是工作流，任务的状态和流转是贯穿整个系统的主线。
社交类。校内网、微博这类应用，属于典型的社交应用，其实也应该把像知乎这类 UGC 应用算进去。社交类以用户关系和内容串联整个系统。 社交类。校内网、微博这类应用，属于典型的社交应用，其实也应该把像知乎这类 UGC 应用算进去。社交类以用户关系和内容串联整个系统。
当然从分类上来说不可能做到尽善尽美，只能说常见的产品属于上面三类，还有一些难以划分在这几类之中。
订单模型
在互联网产品中我们会发现大部分产品都是电商平台，即使是类似文化、阅读的产品也会有产商品的概念贯穿其中。我工作早期做的餐饮系统，也发现无论怎么变化关键的部分都是围绕订单和订单状态设计的。
订单的状态是分析此类系统很好的着手点，从已下单、已支付、已收货、已完成等状态，串联整个系统的其他元素。在处理业务逻辑的时候，考虑订单的状态是否能保持一致，基本能保证系统的逻辑大方向一致。
分析订单模型可以侧重使用 UML 中的状态图，以及 E-R 图建立对象模型。为了降低局部复杂性尝试使用 DDD 的思想进行领域划分、上下文划分。
工作流模型
我们做的内部 ERP 系统大多数都可以抽象成工作流模型，工作流模型的关键元素是任务、参与者、角色。
任务。一个工作流的客体，任务的状态变化体现业务逻辑的推进。 任务。一个工作流的客体，任务的状态变化体现业务逻辑的推进。
参与者。一个工作流的主体，参与者的活动体现工作流过程中关键的方法。 参与者。一个工作流的主体，参与者的活动体现工作流过程中关键的方法。
角色。参与者的分类，用于管理参与者的组织架构和权限。 角色。参与者的分类，用于管理参与者的组织架构和权限。
工作流模型业务分析的关键是参与者角色的识别，往往这类系统角色、关键活动非常多。通过对角色+关键活动组成的用例进行识别，大量系统逻辑都能被分析的清晰并容易理解。
分析工作流模型可以借鉴一些开源工作流产品，除了直接使用这些工作流框架（例如 Apache activiti）之外，可以直接借用它们的定义的概念来自己设计模型。
信息流 (Feed) 模型
设计社交类应用时，无法绕开的模型就是 Feed 模型。信息流模型一般包含信息、信息生产者、信息消费者、推送平台等元素。
信息。用户产生的内容，比如文章、心情、图片或者视频。 信息。用户产生的内容，比如文章、心情、图片或者视频。
信息生产者。产生信息的角色，比如发帖、评论、转发代表的角色。 信息生产者。产生信息的角色，比如发帖、评论、转发代表的角色。
信息消费者。阅读信息的角色，比如拉取个性化 Feed 流、读取热榜列表时代表的角色。 信息消费者。阅读信息的角色，比如拉取个性化 Feed 流、读取热榜列表时代表的角色。
推送平台。负责将信息从生产者推/拉发送到信息消费者的视图中。 推送平台。负责将信息从生产者推/拉发送到信息消费者的视图中。
社交类应用往往信息生产者和信息消费者是同一个人，但是在设计时需要分开看待，否则会混乱。通过信息流模型可以让技术实现更有方向感，比如将精力放在推送平台的建设和性能优化上，否则普通的技术选型无法支撑信息流模型。
租户模型
除了上面的几个模型方式之外，还有一种模型需要考虑，就是租户模型。租户模型与前面讨论的三类应用无关，所有应用都有可能存在多租户的情况。多租户指的是客户希望复制一套属于他自己内容的软件产品，例如多用户建站系统可以开通后复制一套自己的 CMS 系统，通过修改域名和模板就能建站。 互联网产品或多或少都有一些多租户的要求，常见的就是一些 SaaS 平台，比如建站系统、企业微信、用友 ERP、收银系统等。通过租户隔离可以实现双赢的局面。
对软件提供者来说，可以低成本实现倍增收益。 对软件提供者来说，可以低成本实现倍增收益。
对于软件使用者来说，相比于自行研发，可以享受到基础设施共享带来的低成本。 对于软件使用者来说，相比于自行研发，可以享受到基础设施共享带来的低成本。
但是多租户带来的最大的问题是：每个租户潜在的个性化需求和软件提供者希望打造通用解决方案之间的矛盾。认识这个矛盾后，租户一般会使用服务级别协议模型。服务级别协议（SLA）将使用者分为几个级别，一般互联网产品付费策略都会一定程度类似如下划分：
基础版本，共享数据库等所有资源，数据、应用程序不隔离，通过数据字段区分数据集合，后期考虑通过租户。 基础版本，共享数据库等所有资源，数据、应用程序不隔离，通过数据字段区分数据集合，后期考虑通过租户。
数据隔离，共享同样的应用程序，开通专用的数据空间。 数据隔离，共享同样的应用程序，开通专用的数据空间。
应用隔离，私有化部署，数据和应用租户完全物理网络隔离。 应用隔离，私有化部署，数据和应用租户完全物理网络隔离。
定制开发，除了私有化部署外，提供额外的定制开发。 定制开发，除了私有化部署外，提供额外的定制开发。
在产品设计初期，多租户模型容易陷入的误区是把个别租户的个性化需求当做通用需求来做，导致基础版本的业务逻辑混乱，体验复杂。 根据 2-8 定律，大部分租户基础版本已经能满足需要，定制需求往往只是小部分租户需要。使用 SLA 模型可以较好地控制定制需求，当租户确实需要个性化功能，并能接受定制开发成本时，开发定制化需求并进行私有化部署，但不应该污染基础版本。如果产品经理认为这些个性化需求能满足大多数租户的需求时，优化并合入基础版本即可。
另外应用租户模型成本非常高，尤其是多租户下用户打通时带来的复杂性会导致程序难以维护，需要谨慎考虑。