新媒易动态
NEWS CENTER
NEWS CENTER
2021-03-27
架构，简单来理解，就是架设产品的结构。
架构，离不开4个：效率、适用性、稳定性、可扩展性。
B 端产品需要解决企业不断发展过程中遇到的各种问题，所以随着新的商业环境、新的业态、新的模式，必然伴随着催生出新的需求。
每家企业发展的方向不同、策略不同、组织不同，都会导致需求有很多变种，在这种情况下，如何能够通过一款产品满足各种数以万计的企业，就变得异常有挑战性。
没有一个好的产品架构，是无法做到这件事的。
产品架构不好，带来的很多问题，这里不再赘述，主要包括：一碰到新需求就要改底层；改动牵一发而动全身；一碰到新需求就要大改。
我们往往会看到那种结构图，分层分区块，不同层做不同的事，不同块承担不同的角色和职能。
我们要明白所有的架构，最终都为了提效，没能提效的都不是好的架构。
这里引入 2 个思维：
阶段一：线性化思维
就是说比如一个用户进入一个电商网站，他找到一个商品，然后下单，支付，然后商家发货，用户确认收货，交易完成。
如果我们把这些环节都做到一个线性流里，是不是发现这个产品是单层的，所有功能都有序的杂糅其中。
这样一个产品、一套代码，一旦涉及其中一个环节的改动，就会动整个产品、整套代码。
所以开始有了模块的拆分，以及前后端分离。
模块的拆分，能够很好的划分边界，即把相同目标的一些场景功能集成在一起，把不同定位的场景功能排除在外。
那么后面假如只针对A模块进行业务迭代，毫无疑问降低了对整个产品的影响，且更加容易和高效。
模块作为业务层横向的拆分，将线性化的产品变成了离散型。
毫无疑问，线性一定比离散型更快，更高效，但是随着业务的诉求日益增长，任何的快都要建立在满足需求的前提下，否则效率无从谈起。
阶段二：模块化思维
模块化到底是怎么做的呢？
举个例子，从产品角度通俗易懂的讲，比如商品，那么商品中所有的底层数据、商品相关的各种能力（比如创建商品、商品类目管理、商品上下架管理等等）都会被囊括在商品模块（中心）中。模块对外就是提供各种商品相关的接口能力。
模块化还有个好处，就是降低了产品开发的边际成本，同样的商品创建，按照线性开发我肯定还要再做一遍；但是如果集成到一个模块中，我只需要让商品模块可以支撑起他业务的商品创建，做一些轻度扩展，即可满足。
模块化按照颗粒度还可以进行拆分，比如商品模块里面，还可以拆分商品基础信息模块、商品销售信息模块、商品活动信息模块等等。
这些都视业务发展的诉求而定，比如需要针对不同类型的活动，制定不同的商品信息策略，而且这类的业务需求又多又高频，那么是有必要抽出这个模块进行单独迭代的。
模块化有一点比较负责的就是定边界，哪些该放在业务侧，哪些该放在模块服务侧。
我的原则是：高度关联且具备一定通用性的放在模块服务侧，低关联且个性化的功能放在业务开发侧。
上面讲的是单个业务线的模块化，但是随着企业发展，多条业务线并行其实是很正常的，这个时候，每个业务线都需要用到商品，比如一家公司既要发展电商业务，也要发展农产品业务，都会涉及到商品能力的搭建。
理论上来说，如果能用一套商品模块支持 2 个业务线的商品需求，是不是能让降低至少一半的开发成本？
那么问题来了，假如用一套商品模块来支持2个业务的商品需求，会带来什么样的问题呢？
比如电商商品是按照「件」来计算数量的，农产品商品是按照 kg/g 等重量来计算数量的，也就是说商品模块需要支持 kg、g、件等各种计量单位，这还不够，涉及到退货、出入库管理、物流配送费等，都需要做额外的方案兼容。
最后整个商品模块会变得很重，任何不同业务的商品需求都会被迭代到这个商品模块中，成了一个商品中心。
如果同时有 4，5 条线在跑，且他们对商品的需求又各有差异，那么商品中心就会变的很重，这种【重】甚至会反过来影响各个业务线的商品功能，使其变得很难用。
随着越来越【重】，任何一条业务线的商品需求的变更、新增，都会带来成几倍的开发难度和工作量，因为任何一次变更、新增都要基于之前【厚重】的商品模块的产品逻辑来考虑。
这个时候中台的概念应运而生，中台某种意义上来讲，和开放平台非常相似，就是对外提供底层能力。