国内大部分机构产品研发的职责分工上，产品经理更多是业务人员身份，是产品功能的需求方，可以决定做什么，做多长时间，在项目里是甲方爸爸；而研发人员往往多数只是单纯的需求实施方，需求计划都必须听产品经理的，在项目里是乙方孙子。产品经理和研发人员有着天然的甲乙方矛盾，原因很简单：产品经理对开发的要求就是“多快好省”四个字，而研发人员的生产力水平还达不到这个要求，自然而然就会出现产品经理逼疯研发人员，研发人员追打产品经理的戏码。在这里不评判这样的职责分工对不对，反正存在即合理，大环境的思想不是那么容易改变的。我们可以做的是考虑一下研发人员可以怎么做到“多快好省”，通过提升研发人员在产品研发的效率来缓解这个矛盾。
那要怎么提升研发人员的产品研发效率呢？最理想的情况是研发人员手上已经开发好一个个不同的功能组件，当产品经理提出需求的时候，只要把这些功能组件像搭积木一样组合起来就好。但是搭积木简单，在建设过程中怎么设计积木才是最大的难点，这需要研发人员具备一定的架构思维，并在研发过程中根据实际情况的不同有选择地进行应用。
接下来将结合笔者以往的工作经验，结合简单易懂的例子，聊一下产品研发的架构思维。
一、不受业务思维影响
在进行产品研发的时候，低层次的研发人员通常会直接沿用产品经理的业务思路进行设计和编码。比如业务流程是“1 -> 2 -> 3”，那程序代码里就直接写“1 -> 2 -> 3”，业务流程是 “4 -> 5 -> 6”，代码就写成 “4 -> 5 -> 6”，这是典型的技术架构被业务思维影响的情况。
完全按业务思维开发产品，因为和具体业务结合得过于紧密，最终所得到的产品会欠缺灵活性和扩展性，也就是当业务要按市场需求调整的时候，有可能无法支持或需要重构产品，时间周期和人力成本都会很高。
拿下面的造车例子来说，产品经理要做一辆小轿车，工作人员直接按着需求把车做出来了，整个车的部件都是直接按照业务的需要做了个性化定制。小轿车造出来以后，产品经理又要做一辆SUV，因为认为已经做过一次了，产品经理要求一个星期做出来，但由于原来小轿车的部件都是个性化定制的，不能用在SUV上，所以仍然需要从头开始做，也还要一个月才能做出来。
但如果工作人员在做小轿车的时候，考虑到以后还会有做其他车的需求，就可以把车的结构分解为 “4个车轮+发动机+外壳” 三大部分来分别制造（示例，不要太较真），然后再组装成车子。那后续产品经理有SUV、跑车的需求时，可以复用原来小轿车的 “车轮+发动机”，只需制造SUV和跑车的外壳，然后再进行组装就可以了。这样做新车的工作量就可以大幅度减少。
在软件产品的研发上道理是相通的，如果研发人员能在研发产品的过程中，把产品拆解为多个可以通用的模块来开发，那即使未来要调整需求或做新需求，也可以复用部分原来的模块，不需要全部重新开发。这要求研发人员要有不受业务思维影响的架构思维，收到产品经理的需求后要尝试对产品架构按功能模块进行拆分，尽可能形成一些未来可以复用的功能模块或组件，当积累下来的功能模块或组件丰富起来以后，再做新需求效率自然就能得到提高。
二、微服务思维+前后端分离
系统的主流架构演变大体是这样的：传统架构（面向对象）-> SOA架构（面向服务）->微服务架构，三种架构的模式可以参考下面的示例图：
传统架构可以认为是单体应用架构，虽然系统内部会按功能已面向对象的模式拆分了不同模块，但这些模块只能在单体系统内部互相调用，或者已开发组件的方式应用在多个系统代码上面，弊端是难以全局性复用，版本难以统一，升级代价大（需要所有用到组件的系统都进行升级）。SOA架构师面向服务的应用架构，强调系统服务的发布共享，例如示例中将商城的后台各类功能以服务的方式发布到服务总线上，那多个不同的商城应用都可以复用这部分服务，降低前端商城应用的复杂度和研发工作量。微服务架构的理念其实是SOA架构的延续，也在于强调服务的发布共享，但同时提出了服务可独立部署运行的要求，相对SOA架构来说，微服务架构对服务的拆分粒度更细，同时实现了不同服务之间解耦，在性能和复用度上比SOA架构更好。
研发人员要在研发产品时具备微服务思维，是要在设计产品的过程中分析产品功能之间的关系，尽可能将一些通用的功能以微服务的方式独立出来设计和部署，这样做有几个好处：
1、每个微服务都可独立部署运行，在新产品中可以直接组合使用，能大幅开发成本；
2、微服务之间相互独立，对一个微服务的升级替换不会影响其他微服务（只要保证服务接口不变），进行升级改造的关联影响小；
3、微服务模式对系统的性能提升作用明显（独立应用和数据库，更容易扩容）。
其次要坚持前后端分离的架构思维，前端只负责数据展现和交互界面，真正的数据获取及业务处理通过后台微服务来实现。前后端分离的大体架构如下图：
前后端分离的方案对研发产品有以下好处：
1、产品研发过程中前端和后端只要约定接口以后，就可以并行开发，降低整体开发周期；
2、前端开发自由度更大，一些UI展现及客户操作体验的开发无序后端配合改造（互联网应用后期很多都是在优化客户体验而非服务处理）；
3、前后端耦合性不强，在基于技术前瞻性考虑对前端框架升级（例如由react框架调整为vue）时无需改造后端服务。
三、业务逻辑和技术逻辑分离
在产品研发中要有业务逻辑和技术逻辑分离的思维，也就是在设计过程中要把个性业务处理和通用技术处理的不同逻辑梳理出来，并在代码或架构中分离为独立部分。这样做可以让代码结构以及产品架构更为清晰易懂，同时通用技术逻辑独立出来也更有利于复用，以及统一的优化升级。
以一个接口处理服务的代码结构为例，我们可以把对网络报文处理的通用技术逻辑放到service函数中，进行报文转换、格式校验等通用的处理，然后通过配置获取对应的业务方法businessA，执行里面具体的个性业务逻辑。这样后续如果要新增业务功能，只需要写一个新的业务处理方法并纳入配置即可。
此外也可以把业务逻辑和通用技术逻辑放到不同的微服务中，例如在产品中形成一个工作流引擎微服务，为所有应用提供通用的工作流配置、执行、监控功能。
四、接口标准化
对于解决方案的厂商，产品通常还需要输出到客户中部署使用，这时候最大的实施投入就是将产品和客户的内部系统进行对接。如果每次产品都需要按照不同客户的系统情况和需求调整产品的接口，一方面开发投入大，另外一方面也容易造成产品版本的差异，提高了产品版本的维护难度。
对此，产品研发人员需要有坚持产品接口服务标准化的原则，在不同客户的实施中尽可能保证产品原生接口的标准化，可采取接口适配转换的方式来适配客户的个性化接口对接处理。
如上图所示，在实施过程中，产品内核和内部标准接口（或服务）是尽可能保持不变，可以通过增加接口适配器的方式与客户的内部系统进行对接。接口适配器可以按需采用网关（Gateway）或嵌入SDK的方式来实现，主要功能包括网络通讯协议转换（Dubbo、Restful、Socket等协议互通）、报文格式转换（XML、JSON、定长报文等）、报文字段映射（将外部报文字段映射为内部标准），这样针对不同客户的不同报文要求，直接在适配器上进行转换功能的开发或配置就可以实现系统的接入，减少实施周期和成本。
另外对于客户内部系统需要但产品标准接口不具备的字段信息，由于并不会影响产品核心功能的处理，可以在产品存储及接口中增加扩展字段的设计，该字段支持存储key-value形式的字段值（例如JSON字符串）即可，这样即可满足接口适配器所需的字段信息，又不会因为添加字段而影响产品的版本和功能。
五、组件的标准化封装
如前面所述，在产品研发中需要形成各种组件以便于后续复用，这些组件有可能是在研发过程中设计形成，也有可能是直接使用第三方开源或闭源的项目来构建。对于这些组件，研发人员要有一个思想准备：在不远的未来，这些组件有可能因为一些客观原因（例如有重大缺陷、性能问题、技术落后等）而要被替换，为了将来替换时不对产品其他部分有重大影响，将这些组件嵌入产品时就应该做符合自己需求的标准化设计封装，可以参考第三方组件的原生设计接口，但要考虑接口是否具备通用性，对不通用的特性进行修改或废弃。
例如在产品研发中需要使用工作流引擎，可能初期选型在Activiti，Flowable，Jbpm中选择了Jbpm，如果在产品开发中我们完全按照Jbpm的接口标准进行嵌入，那万一后期发现Jbpm存在问题，需要调整为Activiti，就可能需要对嵌入部分甚至工作流相关的功能都要调整才能进行替换。但如果我们在嵌入前对Jbpm的工作流接口做一层封装，在封装层按工作流建立、执行、查询等标准功能提供接口，将jbpm的独有特性在封装层代码中实现，那将来我们要将工作流引擎替换为Activiti，只需要对封装层进行修改就可以直接嵌入产品中使用。
六、技术中台化
技术中台化的更通俗的说法，就是将开发组件升级为微服务。例如在产品中需要进行支付处理，我们可以将支付的功能做成一个支付组件，提供给所有需要支付的代码进行调用，但更好的做法是将这个支付组件的能力升级，将其设计成专门负责支付的微服务对外发布。
将开发组件升级为微服务有以下好处：
1、微服务模式可以保证功能版本一致性，避免了开发组件在多应用调用的版本不一致问题；
2、微服务功能升级对其他应用无影响（接口不变的情况），而开发组件升级需要所有应用重新编译部署；
3、微服务模式可以倒逼研发人员持续设计更完善的功能，而开发组件通常是够用即可（一个服务功能过于单薄说不过去）。
这里提出的是研发人员要有技术中台化的思维，并不是要求所有开发组件都变成微服务，而是希望研发人员在产品研发过程中要认真考虑某一功能是不是升级为微服务更有利于后续的应用和完善。
七、低代码思维
在产品研发中要有低代码思维，也就是在设计上要尽量满足两个原则：重复代码无需人工编写、实现同类功能无需编码。实现低代码的方法有两个方向，一个是从代码编写辅助功能角度出发，通过优化IDE工具、构建开发框架等方式， 实现代码自动生成或底层代码封装，达到让研发人员减少代码编写工作量的效果；另外一个方向是从产品配置化的角度出发，将产品的功能、流程等逻辑进行梳理总结，通过规则配置变更或扩展已有产品能力，以此减少后续产品优化的代码编写量。
在实际产品研发过程中，配置化的思维和做法是更为重要和常见的，而配置化的做法除了可以减少后续代码工作量外，还可以实现产品功能扩展无需编译上线的热部署升级，同时因为实现配置的代码逻辑没有变动，因此只需要对变动的配置进行测试即可，可以极大减少产品测试的范围和工作量。
例如下面报文校验的例子，如果不进行配置化的设计，每增加一个交易或规则，都必须修改代码并编译上线；但如果按配置化的方式设计，交易对应的规则集可以通过配置表动态添加，可以实现校验规则的在线调整生效。
研发人员要尽可能在设计中考虑某些功能是否未来会经常变更或扩展，遇到这类的情况应采取配置化的方式进行设计实现，需要提醒一下，配置化不要只局限于参数的配置，实际上也可以对执行的程序包（例如jar包）进行配置，代码中可以通过反射和动态调用执行所配置的程序包固定方法实现特定逻辑，用来应对配置规则难以穷尽列举的场景。
八、产品模型抽象、放大和包装
从业务运营的角度看，不同领域范围的产品种类非常多，所以需要向市场推出各种各样的产品。但是作为研发人员，一定要有产品建模的思维，将产品需求进行归纳统一，找到不同产品的异同点，以便采取相同或相近的技术来实现，来提高产品研发的效率。产品建模的思路以笔者的经验总结主要有3个步骤：
1、产品模型抽象：这个步骤是基于对业务流程和业务规则的理解，把业务归纳成通用的流程和处理逻辑，这个通用流程和逻辑可以称之为产品模型，同时从技术角度进行产品模型的描述，还原产品本身的技术本质；
2、产品模型的放大：对于抽象好的产品模型，思考未来业务可能存在的扩展方向（可能需求并未提出），对产品模型进行补充完善；
3、产品模型的包装：针对不同业务领域，发散思考该运用该产品模型可以解决的痛点，结合业务领域的特性包装成不同的产品对外推广。
我们下面以银行贷款风控策略系统的需求为例，银行收到客户的贷款申请，会要求客户提供客户自身基本信息和贷款用途信息，在审批贷款的时候需要根据这些信息，按照一定的审批规则来判断客户该笔贷款申请的风险大小，从而确定是否贷款给客户。现在产品经理提出一个需求，希望能做一个系统，根据客户的申请信息自动跑规则并返回是否通过申请。
第一步我们要做产品模型的抽象 ，用技术方式描述系统的核心处理流程。产品模型中考虑到申请数据可能命名不标准，需要将输入数据映射成内部统一的命名格式以便于识别；为了简化规则，部分规则所需的数据可提前加工为变量，再送入规则引擎执行。以此形成可满足业务需求的通用处理流程，如下图所示：
第二部我们对这个产品模型进行放大处理，也就是考虑未来需求可能的扩展。例如考虑有可能未来一些规则需要使用非申请类数据，因此可以增加数据接入模块，通过接口/数据库/文件等方式接入申请数据以外的数据；可能有些场景仅需要对数据进行加工并获取加工后的数据，允许在变量加工的环节直接存储加工结果和返回。形成的更具备扩展性的产品模型如下图：
针对以上产品模型进行的产品研发，就可以考虑结合业务领域来包装产品并对外输出了。对于同样的产品模型，同样的交易处理流程，同一套系统，可以基于不同业务领域的数据和规则模型变成不同的产品系统。例如在产品上放入贷款风控规则模型处理贷款申请数据，就可以包装为信贷风控系统；在产品上放入反欺诈规则模型处理实时交易数据，就可以包装成交易反欺诈系统；应用产品的变量加工能力，可以包装成企业的数据指标加工平台。实际上基础还是一套产品，就可以对外包装出不同的解决方案和系统。
九、复用已有产品模块
在产品研发的过程中，不可避免因为市场方向的调整、技术框架的升级等客观原因，需要对产品进行升级换代，这个是可持续产品的必然发展方向。但一次性对整个产品进行重构，所需要的成本会比较大，带来的风险也会非常高。因此研发人员设计在产品升级换代的方案时，要有复用已有产品模块的思维，通过保留部分非必要改造的原有产品功能模块（例如功能无需调整的模块，或低频应用的模块），来降低实施成本和周期，实现产品升级的平滑过度。
旧的产品模块有可能与新产品的技术架构和体系完全不一样，因此在做方案时要设法兼容已有的功能和技术，最简单的办法是通过将保留功能升级为微服务的方式来实现不同技术框架的功能复用。例如原有产品具有用户管理、订单管理、支付管理等模块，升级方案评估出来支付管理功能已与未来的期望一致，无需改造，但新产品需要采用新的技术框架实现，这时候可以在原有技术下将支付管理模块设计和构建成独立的支付管理微服务（核心功能不动），新产品其他功能按原计划进行升级，最后通过微服务调用的方式整合为一套产品即可。
总结：本篇文章所提及的架构思维是本人在日常研发过程中经常考虑的设计点，是过往工作经验的总结，可以供大家进行参考。但特别提醒这些思维方法只是用于提醒设计过程中要考虑的关键点，并不是架构设计的行动原则，根据项目不同情况，有时候是需要对架构和理性做一定的取舍的，比如因为成本和时间原因，不得不采取成本最低但架构不是最优的方案。不过在研发和架构设计的过程中，多想想总是没有错的，即使采取了折中的方案，研发人员心里还是要清楚怎么才是更合理的方案，这样才能在产品持续的优化中少走弯路，少出现整体推翻重构的浪费情况。
