如何完成业务产品的架构设计？

内部培训过许多产品同学，也认识一下外部的产品同学，普遍存在一个问题：比较多的同学是在面向问题进行产品设计，很少有同学能够拥有业务产品的架构设计能力。这就造成一个问题，大多数的产品经理顶多算是一个需求管理者或者原型设计者。

面向问题进行设计，必然会导致绝大多数的同学会第一时间去寻找问题的答案，比如询问用户想要什么要的效果、竞品是怎么解决这个问题的，这样的结果会逐步让自身的软件产品陷入繁杂的逻辑设计和产品价值的丧失。到后期必然会出现，牵连太多，改不动的局面，更有甚至会出现性能下降、易用性降低的严重问题。

那么如何跳出面向问题设计？

想要跳出面向问题设计，问题进行提升，抽象到更高的维度进行产品设计，这样就能保证既解决了问题，又能够将产品功能限定在有限的约束集中。本文将以面向用户的解决方案为出发点，谈一下业务产品的架构设计，以期共勉。

4层结构完成业务产品架构设计

随着客户业务的演进，对于软件产品来讲，用户的需求将是无穷无尽的，如果面向问题设计，那么对于客户来讲，就是一个需求一个需求的价值，只是满足了客户对于软件产品使用的问题，却没有从根本上为客户提供价值的提升。

所有的产品都应该给客户带来价值，那么到底是产品的什么为客户带来价值呢？笔者认为：面向客户业务问题的解决方案，是产品提供价值的核心，本文基于解决方案提出4层结构来完成业务产品架构设计。

层级0（L0）：解决方案-立足于客户价值，为客户能够买单提供基础；

层级1（L1）：业务模块-独立的微服务，可以理解为支持解决方案的最小业务支撑单位；

层级2（L2）：页面和逻辑-每一个独立的业务模块，必然提供的一项业务能力，业务能力的表达是通过页面和逻辑进行呈现的，每一个页面又拆解为不同的页面区块（每个区块是基于模块最小的功能呈现）

层级3（L3）：功能点和接口-既然是能力，必然包括涉及的功能点和接口能力，实现业务功能和跨解决方案的数据交互能力。

4层的产品架构设计，从解决方案出发，既立足于客户价值的输出，也可以将业务产品框定在有限的约束集中，为产品的发展和迭代打下坚实的基础。

本文仅供参考，后续在为各位补充4层产品架构的详细设计思路；

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！