平臺化設計產品存在的問題

小霖2012發表於2023-04-01

關於產品的一些思考

產品：在將業務抽象成產品或元件時，需要考慮多個因素，包括閉環條款、永續性、可重用性等。只有當業務具備這些關鍵特徵時，才能適合抽象成產品。否則，應該考慮將其作為元件的形式存在，或者使用規則引擎來視覺化出來，使用條件積木和行為積木來表達其控制邏輯和操作步驟。

例如，限購、阻斷和實名校驗等業務沒有明確的閉環條款，因此不太適合作為產品存在。相反，這些業務更適合作為可重用的元件存在，供其他產品呼叫。此外，使用規則引擎視覺化這些業務可以幫助更好地管理其輸入和輸出，並使用條件積木和行為積木來表達其控制邏輯和操作步驟。

在考慮將業務抽象成產品或元件時，還需要考慮其永續性和可重用性。業務應該是非臨時的，即它需要在相對長的時間記憶體在，並且在此期間不會發生根本性變化。如果一個業務存在較高的變動性和不確定性，那麼將其抽象成元件可能會增加額外的複雜度和風險。

總之，將業務抽象成產品或元件需要綜合考慮多個因素，包括閉環條款、永續性、可重用性等。透過合理地設計產品和元件，可以提高開發效率和業務靈活性，從而更好地滿足使用者的需求和期望。

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;
    }
}

笛卡爾積問題

在構建一個實物商品下單的產品時，需要組合多個產品，包括儲值卡產品、實物商品產品、支付產品、優惠計算產品、快遞產品和風控產品。同時，需要注意到同城配送產品在此場景下不適用，因此應該被剔除。這個過程需要考慮到各個產品之間的關聯和依賴關係，並且需要進行笛卡爾積操作來確定最終組合的可能性和組合數目。

然而，如果構建一個虛擬商品下單的產品，組合的產品就會有所不同。在這種情況下，儲值卡產品、虛擬商品產品、支付產品、優惠計算產品、快遞產品和風控產品都是需要的。這種場景下的產品組合與實物商品下單的產品組合有所不同，因此需要重新組裝一個新的產品組合，以便滿足需求。

這樣的組合產品不僅需要在構建時進行考慮，同時也需要在後續的維護和更新中進行相應的操作。這可能會導致大量的重複性工作，而且容易出現錯誤。為了解決這個問題，可以採用元件化和模組化的設計方法來簡化產品的組裝和維護。在這種方法中，每個產品都可以作為一個獨立的元件，可以與其他元件相互連線和組合，形成一個完整的產品。這樣可以有效降低組合產品的複雜度和維護成本，提高產品的開發效率和質量。

總之，產品組合和維護是一個複雜的過程，需要考慮到各個產品之間的關聯和依賴關係，並進行合理的組合和剔除。採用元件化和模組化的設計方法可以有效簡化產品的組裝和維護，提高產品的開發效率和質量。如果設計不好的話，後期會有很多的疊加的笛卡爾積，導致產品、組合產品不斷的膨脹，變成一個難以維護的系統。

相關文章