一、发生背景
研发人有技术架构，产品经理有业务架构（通常是一个人），当一个技术架构师不懂业务架构的时候，就会出现如下对话。
架构师小孙：“业务本来就发展迅速的，那天他还和我说想根据商品体积拆分的，被我挡了回去”。
我相信大家经常遇到类似的问题，然而如果技术架构师懂业务架构，就会变成下面的对话场景。
架构师小孙：“哈哈，预知未来本来就是架构师的职责”。
下面我们就来学习下如何，如何让技术架构师具有预知未来业务发展的能力。
二、解决方案
映射（Mapping）：所有的需求可以映射到如下系统化、结构化的语言，计算机程序是在什么样的场景（事件）下开始行动，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织/角色）执行，执行后会产生哪些数据（实体）。但是针对一个特定的场景来说，顺序（活动）、规则（任务）由谁（组织/角色）是更容易多变的。
识别（identify）&询问（ask about****）：所以我们在和产品经理沟通需求的时候，最主要的是识别顺序、规则（组织/角色通常在权限系统RBAC模型可以配置，可以不用多考虑）。如何快速识别顺序和规则呢？
2、规则：通常是（ IF A then B）模式，他通常在在每个顺序节点下面，例如在商品引入的“洞察”的业务活动时候，如果发现有如下话术“如果商品是大家电，需要考虑竞对价格因子”，“如果商品是滞销类型，可以不用参与洞察”等等。如果发现这类术语，基本可以判断是规则；当然还有些规则比较隐蔽，需要我们来挖掘，例如案例中“订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分”，这里其实并没有那么明显的（ IF A then B）模式，但是通常有形容词的动词，都有可能变化（例如 按照库存状态拆分）。但是如果在挖掘下或仔细思考下，就可以看出出来这个两个拆分逻辑，一定是有条件或顺序的，否则同一个订单拆分会乱套的。如果在这个时候，我们在追问下产品2个问题，“1、这个规则，是否在特定的条件下才有效，例如客户/渠道/品类等不同端或渠道、时间段、优先级顺序”。“2、这个规则，在不同客户/渠道/品类等不同端或渠道，还有可能其他规则“。同样，如果产品经理不确定，可以让产品经理在调研下，有个这个信息，在系统架构处理的时候，就可以多种方式处理扩展性，最简单代码的可以做策略模式，或利用配置文件、规则引擎dools等实现扩展性。
三、案例分析
产品经理小李：“这次我们要做个业务，订单履约。这是我的PRD，今天我们一起看下。“
产品经理小李：“是的，大的逻辑是这样的”
产品经理小李：我调研了4个客户，3个订单渠道，以及竞品都是经过这个这几个环节。目前看没有在新节点的可能性。
产品经理小李：“额，我我觉得是“
—— 一段时间后
架构师小孙：“OK。这块我设计为可扩展性的”
四、总结陈述
来源：京东云开发者社区
作者：京东零售 李春丽（未经授权请勿转载）