以一个技术架构师的角度，承接业务架构或在没有业务架构的时候，如何判断业务变化趋势而对系统架构提前做出反应？

一、发生背景

研发人有技术架构，产品经理有业务架构（通常是一个人），当一个技术架构师不懂业务架构的时候，就会出现如下对话。

技术工程师小王：“产品经理又改需求，昨天和我说订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分”

架构师小孙：“业务本来就发展迅速的，那天他还和我说想根据商品体积拆分的，被我挡了回去”。

技术工程师小王：“厉害，还是你有话语权”。

我相信大家经常遇到类似的问题，然而如果技术架构师懂业务架构，就会变成下面的对话场景。

技术工程师小王：“产品经理又改需求，昨天和我说订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分，还好，你上次和我说这块规则是多变的，让我把不同订单拆分逻辑，拆分为原子化，我改下配置就搞定，不愧是架构师，你怎么知道这块多变？难道会占卜？”

架构师小孙：“哈哈，预知未来本来就是架构师的职责”。

技术工程师小王：“快教教我吧”。

下面我们就来学习下如何，如何让技术架构师具有预知未来业务发展的能力。

二、解决方案

技术架构师需要了解业务架构的知识，但是又不用像产品经理知道那么多，例如价值链等等概念。他需要知道的如何识别业务发展变化趋势，并把对应部分的技术架构做好结构化、扩展性。我今天就来介绍一个简单的方法- MIT 知识模型。简单来说是 1：映射（Mapping） 2 识别（identify） 3 询问（ask about）

映射（Mapping）：所有的需求可以映射到如下系统化、结构化的语言，计算机程序是在什么样的场景（事件）下开始行动，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织/角色）执行，执行后会产生哪些数据（实体）。但是针对一个特定的场景来说，顺序（活动）、规则（任务）由谁（组织/角色）是更容易多变的。

识别（identify）&询问（ask about**）：所以我们在和产品经理沟通需求的时候，最主要的是识别顺序、规则**（组织/角色通常在权限系统 RBAC 模型可以配置，可以不用多考虑）。如何快速识别顺序和规则呢？

1、 顺序：一个场景经过的多个业务活动，这个通常产品经理的业务流程图会展示，例如商品引入功能，需要经过“洞察”、“选品”、“招商”、“法务”等多个业务流程节点。找到这个顺序后，主要问产品 2 个问题就可以判断是否多变，“这个顺序，是否在不同客户/渠道/品类等不同端或渠道不同”，“这个顺序，是否因为短期上线压力，妥协只是做了简化”。通常产品经理在调研的时候会获得这个信息。如果产品经理不确定，可以让产品经理在调研下，有个这个信息，在系统架构处理的时候，就可以有多种方式处理扩展性，可以做出多个微服务，或者利用流程引擎工具实现扩展性。

2、规则：通常是（ IF A then B）模式，他通常在在每个顺序节点下面，例如在商品引入的“洞察”的业务活动时候，如果发现有如下话术“如果商品是大家电，需要考虑竞对价格因子”，“如果商品是滞销类型，可以不用参与洞察”等等。如果发现这类术语，基本可以判断是规则；当然还有些规则比较隐蔽，需要我们来挖掘，例如案例中**“订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分”，**这里其实并没有那么明显的（ IF A then B）模式，但是通常有形容词的动词，都有可能变化（例如 按照库存状态拆分）。但是如果在挖掘下或仔细思考下，就可以看出出来这个两个拆分逻辑，一定是有条件或顺序的，否则同一个订单拆分会乱套的。

如果在这个时候，我们在追问下产品 2 个问题，“1、这个规则，是否在特定的条件下才有效，例如客户/渠道/品类等不同端或渠道、时间段、优先级顺序”。“2、这个规则，在不同客户/渠道/品类等不同端或渠道，还有可能其他规则“。同样，如果产品经理不确定，可以让产品经理在调研下，有个这个信息，在系统架构处理的时候，就可以多种方式处理扩展性，最简单代码的可以做策略模式，或利用配置文件、规则引擎 dools 等实现扩展性。

三、案例分析

通过以上简单的模型，我们就客户还原架构师小孙，在和产品经理沟通的需求场景。

产品经理小李：“这次我们要做个业务，订单履约。这是我的 PRD，今天我们一起看下。。。。。。“

架构师小孙：“PRD 写的挺详细的。通过我这个 PRD。我们理解了订单履约大概要实现的功能，你看我这样说是否正确：订单履约功能需求，需要读取订单数据，在经过拆分、打标顺序，产生多个拆单后订单，并传输给物流系统。通常这些工作，由系统自动处理无需人员干涉。是吧？

产品经理小李：“是的，大的逻辑是这样的。”

架构师小孙：“这里拆分、打标顺序，否在不同客户/渠道/品类等不同端或渠道不同。是否因为短期上线压力，妥协只是做了简化？“

产品经理小李：我调研了 4 个客户，3 个订单渠道，以及竞品都是经过这个这几个环节。目前看没有在新节点的可能性。

架构师小孙：“好的，那我为了成本考虑。我先把流程节点设计为固定，后续你这里发现有多变的场景及时通知我，另外我看你在拆分环节，提到订单按照库存状态拆分，这里是所有订单都按照库存状态拆分吗？”

产品经理小李：“额，我我觉得是“

架构师小孙：“我建议你在调研下，不同客户/渠道/品类等不同端或渠道下，是否有不同逻辑”，通常在有形容词的动作，都是可能变化的。

—— 一段时间后

产品经理小李：“嗯是的，客户 A 说他们除了库存、还有运费、礼品卡、商品体积拆分逻辑，这些会按照顺序来依次进行“。

架构师小孙：“OK。这块我设计为可扩展性的”

四、总结陈述

看，架构师有业务预知性或者业务敏感性其实挺简单的，就是找对位置，多问些问题，就可以为一线研发减少很多工作量。这个能力在很多地方，也可以称为业务敏感性。所以系统扩展性设计一定离不开业务输入，但是如何通过几个简单的问题，就可以快速找到业务多变的地方，就是我本次分享的 MIT 模型解决的。大家也可以请根据一个业务场景，按此 MIT 知识模型分析下业务多变的点。

来源：京东云开发者社区

作者：京东零售 李春丽（未经授权请勿转载）