认识达内从这里开始

随着互联网的不断发展，越来越多的人都在通过自学或者参加达内培训来学习软件编程开发等技术，而本文我们就简单来了解一下，技术架构师需要掌握哪些知识点。

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

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

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

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

2、规则：通常是(IFAthenB)模式，他通常在在每个顺序节点下面，例如在商品引入的“洞察”的业务活动时候，如果发现有如下话术“如果商品是大家电，需要考虑竞对价格因子”，“如果商品是滞销类型，可以不用参与洞察”等等。如果发现这类术语，基本可以判断是规则;当然还有些规则比较隐蔽，需要我们来挖掘，例如案例中“订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分”，这里其实并没有那么明显的(IFAthenB)模式，但是通常有形容词的动词，都有可能变化(例如按照库存状态拆分)。但是如果在挖掘下或仔细思考下，就可以看出出来这个两个拆分逻辑，一定是有条件或顺序的，否则同一个订单拆分会乱套的。如果在这个时候，我们在追问下产品2个问题，“1、这个规则，是否在特定的条件下才有效，例如客户/渠道/品类等不同端或渠道、时间段、优先级顺序”。“2、这个规则，在不同客户/渠道/品类等不同端或渠道，还有可能其他规则“。同样，如果产品经理不确定，可以让产品经理在调研下，有个这个信息，在系统架构处理的时候，就可以多种方式处理扩展性，简单代码的可以做策略模式，或利用配置文件、规则引擎dools等实现扩展性。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音达内三江区域学习了解。