支撑 MVP，架构师需要做什么

我们在建设一个产品的过程中，往往受制于资源的限制以及进度的要求，需要对产品的功能进行一定的裁剪。一般情况下，我们会考虑建设 MVP（Minimum viable product），用最短的节奏完成功能的交付。

在产品视角，有各种的方法论和流程指导去确定一个 MVP。但是，在产品视角，MVP 不是交付一个成本的部分组件，而是交付一个不完整但是可用的原型产品。

基于这个要求，在架构上，往往 MVP 要求一个比较完整的架构设计，同时要实现的基础能力可能也会比较多。所以，用原型迭代的方法论去实现产品能力，在架构设计上也需要考虑取舍的技巧。

首先，做业务产品，首先是设计模型。考虑到简化工作量，我们设计第一版模型的时候需要对实体和属性进行裁剪。这里面有几个原则（这里拿交易系统来举例子）：

• 第一版聚焦在交易模型，暂时忽略配置模型。

• 没必要给产品未明确的功能预设计模型。后续的迭代随着产品功能的增加，模型必然会有扩充，重构是不可避免的。我们可以考虑模型的可扩展性，但是在没有考虑清楚的情况下没必要在第一版本就预留很多实体和关系。

• 业务主键必须定义清楚。我们在物理模型中一般会设计一个没有业务含义的技术主键（比如 UUID 或者自增），但是在领域模型中的业务主键更关键。业务主键一般定义了业务的幂等特性。虽然第一版本的模型在许多地方可以裁剪，但是业务主键的定义必须明确。同时，我们需要通过数据流回放的方式来验证我们的业务主键设计具备合理性并能满足未来的需要。

其次，是服务的设计。服务的设计需要满足最小可用原则。

• 在第一版本中，必须提供的是新增和查询的服务。修改服务视情况决定是否提供。删除服务可暂时不提供。

• 服务中的字段和模型保持一致，无需做过多的预留存。特别是没必要定义一堆的扩展字段。

• 批量服务可暂时不提供。包括批量导入、报表类查询。

• 内部服务暂时不需要对外暴露。比如风险管理，通过内部的识别已经可以定义出风险，暂时不需要提供人工录入或者从其他系统同步的服务能力。

第三，对于外部集成，遵循非必需暂缓的原则。

• 如果内部自循环可以满足功能，可先不做外部集成。比如支付工具，如果可以用余额满足 MVP 的要求，可以先不对接外部渠道。

• 如果内部自循环无法达到产品要求，考虑逐条对接的方式。比如支付工具，可以先对接 MV 信用卡，其它支付工具可以逐步迭代完成。

• 由于 MVP 产品一般交易量都不是太大，可以暂时先不考虑渠道的限流、异步发送、批量打包等能力。

最后，对于页面的设计。在 MVP 版本中：

• 朴素的实现为主，提供必要的导航和操作页面。

• 一般的操作页面以直观的表格为主，除非产品特性要求没必要设计过于复杂的动态效果。

• 前端的一些校验可以暂缓，先用后端校验替代。因为后端校验是必需不可少的。

我们最近在做外汇客户风险管理产品的 MVP。考虑到需要尽快在 2 个月内推出第一个版本，我们在架构上做了如下取舍：

• 完整实现指标-识别-告警-处置的风险管理流程。

• 完整定义风险库模型，但不实现风险库相关的服务。

• 指标上进行裁剪，聚焦远期交易，聚焦非聚合类指标。

• 告警上只提供一个渠道：钉钉。

• 处置上只实现一类处置方式：人工共担。

• 风险回溯分析功能暂不实现。

• 第一版本中指标定义、识别规则、告警规则、处置规则不实现维护界面，通过 DML 进行维护。

总之，在 MVP 产品的架构设计中，需要遵循无必须不预留、逐个迭代、最简实现的原则。在唯快不破的互联网时代，尽早推出产品是 First Priority 需要考虑的事情。