关于产品的一些思考

产品:
在将业务抽象成产品或组件时,需要考虑多个因素,包括闭环条款、持久性、可重用性等
。只有当业务具备这些关键特征时,才能适合抽象成产品。否则,应该考虑将其作为组件的形式存在,或者使用规则引擎来可视化出来,使用条件积木和行为积木来表达其控制逻辑和操作步骤。

例如,限购、阻断和实名校验等业务没有明确的闭环条款,因此不太适合作为产品存在。相反,这些业务更适合作为可重用的组件存在,供其他产品调用。此外,使用规则引擎可视化这些业务可以帮助更好地管理其输入和输出,并使用条件积木和行为积木来表达其控制逻辑和操作步骤。

在考虑将业务抽象成产品或组件时,还需要考虑其持久性和可重用性。业务应该是非临时的,即它需要在相对长的时间内存在,并且在此期间不会发生根本性变化。如果一个业务存在较高的变动性和不确定性,那么将其抽象成组件可能会增加额外的复杂度和风险。

总之,将业务抽象成产品或组件需要综合考虑多个因素,包括闭环条款、持久性、可重用性等。通过合理地设计产品和组件,可以提高开发效率和业务灵活性,从而更好地满足用户的需求和期望。

TMF产品的定义

其实在毗卢的文章中没有对产品有名气的定义,在上面我按我之前对平台设计的理解给了产品定义,就是需要考虑是否有闭环、可持久性和可重构的业务场景。我们来看下TMF提供的例子,例子内容来自https://www.ryu.xin/2022/09/24/lattice-overlay-product/

我的理解是一个团购的产品,可能是团购返现、也可能是普通的团购,他在下单的过程中的不同步骤有自己的业务场景,能够形成闭环

定义团购场景 “GroupBuyProduct” 产品

@Product(code = GroupBuyProduct.GROUP_BUY_PRODUCT_CODE, name = "Group Buy Trade Product")
public class GroupBuyProduct extends ProductTemplate {

    public static final String GROUP_BUY_PRODUCT_CODE = "lattice.productGroupBuyProduct";

    @Override
    public boolean isEffect(ScenarioRequest request) {
        if (request instanceof BuyScenarioRequest) {
            boolean effect = StringUtils.equals("groupBuy", ((BuyScenarioRequest) request).getSource());
            System.out.println("GroupBuyProduct effect status:" + effect);
            return effect;
        }
        return false;
    }
}

笛卡尔积问题

在构建一个实物商品下单的产品时,需要组合多个产品,包括储值卡产品、实物商品产品、支付产品、优惠计算产品、快递产品和风控产品。同时,需要注意到同城配送产品在此场景下不适用,因此应该被剔除。这个过程需要考虑到各个产品之间的关联和依赖关系,并且
需要进行笛卡尔积操作来
确定最终组合的可能性和组合数目。

然而,如果构建一个虚拟商品下单的产品,组合的产品就会有所不同。在这种情况下,储值卡产品、虚拟商品产品、支付产品、优惠计算产品、快递产品和风控产品都是需要的。这种场景下的产品组合与实物商品下单的产品组合有所不同,因此需要重新组装一个新的产品组合,以便满足需求。

这样的组合产品不仅需要在构建时进行考虑,同时也需要在后续的维护和更新中进行相应的操作。这可能会导致大量的重复性工作,而且容易出现错误。为了解决这个问题,可以采用组件化和模块化的设计方法来简化产品的组装和维护。在这种方法中,每个产品都可以作为一个独立的组件,可以与其他组件相互连接和组合,形成一个完整的产品。这样可以有效降低组合产品的复杂度和维护成本,提高产品的开发效率和质量。

总之,产品组合和维护是一个复杂的过程,需要考虑到各个产品之间的关联和依赖关系,并进行合理的组合和剔除。采用组件化和模块化的设计方法可以有效简化产品的组装和维护,提高产品的开发效率和质量。如果设计不好的话,后期会有很多的叠加的笛卡尔积,导致产品、组合产品不断的膨胀,变成一个难以维护的系统。

标签: none

添加新评论