平台化设计产品存在的问题
关于产品的一些思考
产品：
在将业务抽象成产品或组件时，需要考虑多个因素，包括闭环条款、持久性、可重用性等
。只有当业务具备这些关键特征时，才能适合抽象成产品。否则，应该考虑将其作为组件的形式存在，或者使用规则引擎来可视化出来，使用条件积木和行为积木来表达其控制逻辑和操作步骤。
例如，限购、阻断和实名校验等业务没有明确的闭环条款，因此不太适合作为产品存在。相反，这些业务更适合作为可重用的组件存在，供其他产品调用。此外，使用规则引擎可视化这些业务可以帮助更好地管理其输入和输出，并使用条件积木和行为积木来表达其控制逻辑和操作步骤。
在考虑将业务抽象成产品或组件时，还需要考虑其持久性和可重用性。业务应该是非临时的，即它需要在相对长的时间内存在，并且在此期间不会发生根本性变化。如果一个业务存在较高的变动性和不确定性，那么将其抽象成组件可能会增加额外的复杂度和风险。
总之，将业务抽象成产品或组件需要综合考虑多个因素，包括闭环条款、持久性、可重用性等。通过合理地设计产品和组件，可以提高开发效率和业务灵活性，从而更好地满足用户的需求和期望。
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;
}
}
笛卡尔积问题
在构建一个实物商品下单的产品时，需要组合多个产品，包括储值卡产品、实物商品产品、支付产品、优惠计算产品、快递产品和风控产品。同时，需要注意到同城配送产品在此场景下不适用，因此应该被剔除。这个过程需要考虑到各个产品之间的关联和依赖关系，并且
需要进行笛卡尔积操作来
确定最终组合的可能性和组合数目。
然而，如果构建一个虚拟商品下单的产品，组合的产品就会有所不同。在这种情况下，储值卡产品、虚拟商品产品、支付产品、优惠计算产品、快递产品和风控产品都是需要的。这种场景下的产品组合与实物商品下单的产品组合有所不同，因此需要重新组装一个新的产品组合，以便满足需求。
这样的组合产品不仅需要在构建时进行考虑，同时也需要在后续的维护和更新中进行相应的操作。这可能会导致大量的重复性工作，而且容易出现错误。为了解决这个问题，可以采用组件化和模块化的设计方法来简化产品的组装和维护。在这种方法中，每个产品都可以作为一个独立的组件，可以与其他组件相互连接和组合，形成一个完整的产品。这样可以有效降低组合产品的复杂度和维护成本，提高产品的开发效率和质量。
总之，产品组合和维护是一个复杂的过程，需要考虑到各个产品之间的关联和依赖关系，并进行合理的组合和剔除。采用组件化和模块化的设计方法可以有效简化产品的组装和维护，提高产品的开发效率和质量。如果设计不好的话，后期会有很多的叠加的笛卡尔积，导致产品、组合产品不断的膨胀，变成一个难以维护的系统。