共计 2534 个字符，预计需要花费 7 分钟才能阅读完成。
大家好，明天咱们来分享业务架构，然而咱们并不是以产品经理角度讲述一个业务架构是什么以及如何做？而是以一个技术架构师的角度，讲述如何承接业务架构或在没有业务架构的时候，如何判断业务变化趋势而对系统架构提前做出反馈。
一、产生背景
研发人有技术架构，产品经理有业务架构（通常是一个人），当一个技术架构师不懂业务架构的时候，就会呈现如下对话。
技术工程师小王：“产品经理又改需要，昨天和我说订单依照库存状态拆分，我刚刚上线明天又和我说依照促销类型类型拆分”
架构师小孙：“业务原本就倒退迅速的，那天他还和我说想依据商品体积拆分的，被我挡了回去”。
技术工程师小王：“厉害，还是你有话语权”。
我置信大家常常遇到相似的问题，然而如果技术架构师懂业务架构，就会变成上面的对话场景。
技术工程师小王：“产品经理又改需要，昨天和我说订单依照库存状态拆分，我刚刚上线明天又和我说依照促销类型类型拆分，还好，你上次和我说这块规定是多变的，让我把不同订单拆分逻辑，拆分为原子化，我改下配置就搞定，不愧是架构师，你怎么晓得这块多变？难道会占卜？”
架构师小孙：“哈哈，预知将来原本就是架构师的职责”。
技术工程师小王：“快教教我吧”。
上面咱们就来学习下如何，如何让技术架构师具备预知将来业务倒退的能力。
二、解决方案
技术架构师须要理解业务架构的常识，然而又不必像产品经理晓得那么多，例如价值链等等概念。他须要晓得的如何辨认业务倒退变化趋势，并把对应局部的技术架构做好结构化、扩展性。我明天就来介绍一个简略的办法 - 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 常识模型剖析下业务多变的点。
起源：京东云开发者社区
作者：京东批发 李春丽（未经受权请勿转载）