产品架构的本质

业务场景要具象，系统场景要抽象。从这句话可以看到一个漏斗，从大量的具象化需求中，抽象出一个模型，就好比人类一样，我们能够完成各种各样的工作，取决于我们系统的各个器官的通力合作。不管我们做什么工作，是不是都是这几个器官。当然人的构造也在逐步进化中，不断适应系统，不断用进废退。

各个抽象化模块的连接。

所以，产品架构本质上，是将各种具象化的场景进行归类总结，形成一个通用化的框架，这个框架可以做到以不变应万变。

举个例子，电商运营需要配置商品进行上架销售，但不管怎样，都离不开品牌、分类、属性、SKU、SPU、价格，各个模块相互独立，但彼此又有联系。

不管运营要做多少种运营动作，都可以抽象出这么多模块出来，两两组合就可以产出各种花样出来。

要做到这一点，产品经理需要具备几个能力：

一、很强的业务前瞻性

做一个需求，就需要把未来的整体业务蓝图描绘出来，也就是未来业务要做成什么样，业务场景会有哪些，需要快速识别出来，特别是各种异常场景。

业务梳理是产品架构完善的第一个前提，有人说直接照搬业界成熟系统不就好了，那这样就没产品经理什么事了，业界经验只能是参考，即使业务做法做得再对，我们也需要通过业务的输入进行方案的验证。

所以，业务的场景的梳理和完善是输出完善的产品架构的关联。

这个要求产品经理要懂业务，还要懂业务的本质，才能够抽象出本质。

二、抽象能力

业务场景这么多，哪些是正确的业务流程，哪些是错误的业务流程，怎么评判业务流程的对与错。

有几点：

• 这个业务流程能不能使得多角色的运营效率不断提高，实现1 1大于2
• 这个业务流程可以和其他流程更好的串联
• 这个业务流程尽可能不会破坏当前的产品模型

就好比人类一样，祖先是有多么大的智慧能够将人类的这么多操作动作抽象出了大脑、肺、心脏、胃、肝等等器官，各个器官之间还能各司其职。

从具象化的场景，抽象出产品模型出来，这个很关键。

怎么做到？

类比，学习，模仿，归纳总结，多深挖问题本质，多问几个为什么。

三、划清模块之间的边界

既然模型要抽象，那业务的场景尽可能不要耦合到模型当中，不然一旦业务场景一变，模型就要跟着调整。

所以考验一个模型做得好不好，就看够不够抽象，做这个功能的时候，是不是把未来的七八个场景都考虑进去了。

记得我大厂工作的时候，领导经常会问一个问题，这个功能其他场景能复用吗，万一需求变了，我们的方案要调整吗？

既然模型要抽象，方便组合成不同的具象化场景，那模块之间要分清界限，分清界限的标准是

1. 模块内容发生变更，不会影响到其他系统，各系统之间要解耦
2. 各模块之间相互组合更加的简便

总结一下，产品架构就是把具象的场景抽象化，抽象成各个独立的模块，再通过各个模块之间的联系组合成不同的功能，进而满足业务的各种场景。

模块越抽象，越解耦，我们能够满足的业务场景就越多，也更有利于系统的延展。

当然，有时候也要结合业务的实际情况，不能因为要考虑一个完整的架构花了大量的时间做业务调研，但是市场的先机已经被他人占领了。有时候系统也是可以演化出来的，没有对错，只有合不合适。

版权声明

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