如何從微服務角度建立可擴充套件的電子商務資料模型？ - fabric

如果線上銷售產品是您業務的核心部分，那麼您需要構建可擴充套件，靈活且快速的電子商務資料模型。諸如Shopify和BigCommerce之類的大多數現成供應商都是為每月銷售幾百萬美元訂單的小型商店而建，因此許多從事大規模工作的電子商務零售商開始研究建立定製解決方案。

本文將研究您自己開始構建此基礎結構需要做什麼。有哪些方面需要考慮？資料模型可能是什麼樣？涉及多少工作？

在此過程中，我們將探索替代方案：基於API的商務平臺，可跨產品目錄，定價和訂單為您管理資料，而無需將您鎖定在一個整體中，而無需重新平臺。

客戶

首先，您需要考慮誰將從您的電子商務應用程式中購買商品。結果如何在資料庫中建模客戶資訊？您可能需要基本資訊，例如客戶的姓名，電子郵件地址等。是否希望客戶能夠在系統中建立配置檔案？還是每次他們想購買東西時填寫表格？

剛開始時，基本模型可能如下所示：

如果希望客戶擁有持久的配置檔案，則需要建立某種方式讓他們登入到您的應用程式。隨著更多實際需求的發展，您可能還希望跟蹤其登入嘗試歷史記錄和密碼歷史記錄。

您可能還需要考慮您的客戶是否屬於大型組織。如果可以，他們將如何處理密碼重置？他們是否需要單點登入或OAuth支援？

深入探討：地址

您是否注意到到目前為止顯示的任何資料模型中都沒有與客戶繫結的地址？將客戶的地址作為這些模型的一部分可能是您的第一個傾向。然而，大多數客戶將有多個地址和多種類的地址，如付款和發貨。B2B零售商可能還必須根據他們所支援的倉庫和辦公室的數量來考慮多個送貨地點。

如果帳單和送貨地址不同，該怎麼辦？好吧，您需要做的不僅僅是在Customer表中新增額外的列！沒那麼簡單。

那麼，儲存帳單地址如何影響應用程式的可伸縮性？

如果將付款和運輸區域劃分為各自具有各自資料庫的單獨的（微）服務，則將帳單和付款地址放入該Customer區域將導致具有“聊天”服務。構建微服務時，這是眾所周知的設計氣味。

為避免出現此問題，最好將地址放在需要它們的適當區域/服務中，但這樣做會使資料模型變得更加複雜。

避免這種複雜性的一種方法是考慮由API優先軟體提供商提供的訂單管理系統（OMS）。使用此軟體，您可以將OMS整合到資料模型中，而無需花費數月的工程時間。 

產品和目錄

當您進入商店（面對面或數字化購買）時，看到的第一件事是準備好要購買的產品，並且通常在顯示時會考慮您可能的購物方式。

對於電子商務Web應用程式，您可能需要突出顯示以下內容：

• 暢銷產品
• 熱門產品
• 新產品
• 通過搜尋條件瀏覽產品的能力

向客戶提供這些資訊意味著您首先需要跟蹤有關產品的大量資料：其價格，歷史購買資料等。

讓我們來看看為產品目錄建立資料模型的“第一槍”：

這是Product一張包含一些基本資訊的表格，例如產品名稱，SKU和價格。該產品還連結到另一個表，該表代表與該產品相關聯的各種類別。您也可以策略性地在Product表中新增索引和全文搜尋，以使站點訪問者能夠有效地搜尋各種產品。

這是一個體面的第一次嘗試。但是，要獲得更加現實和實用的電子商務產品目錄，您需要支援更多要求，例如：

• 跟蹤定價歷史記錄，以便站點管理員可以分析產品定價趨勢
• 支援相關產品以顯示在產品頁面上
• 合併產品供應商，以便客戶可以檢視單個供應商/公司出售的所有產品

為了解決這些額外的需求，您可能會得到以下資料模型：

該模型仍然不完美，因為它會將您的價格嵌入到產品本身中，但是至少它可以讓您保持以前的定價歷史。

另一個選擇是將您的電子商務商店與定價和促銷引擎整合，該引擎由API優先為您定價的軟體提供商提供。這樣，您可以根據使用者的意圖，位置，購物車或訂單歷史記錄向不同的使用者推出不同的價格。

定價模型

儘管更復雜的產品資料模型在同一張表中仍具有產品價格，但這在真正的大規模應用中可能不是最好的選擇。

考慮到您的組織有多個部門，例如庫存/倉庫，銷售，市場營銷，客戶支援等。您可能擁有專用的系統，使銷售商可以更改商品的價格，因為他們是確定商品價格的專家。如果我們將價格留在核心Product表中，這將導致跨邊界/服務/跨有界上下文的通訊。

因此，您可能希望將產品價格儲存在銷售部門擁有的資料儲存下。但是請不要忘記，尚未考慮多種不同的“價格”，包括：

• 向供應商購買庫存時的價格（成本）
• 客戶銷售價
• 折扣價
• 廠商建議零售價

在組織結構的背景下處理所有這些問題將需要對資料模型進行更多的探索和增加複雜性。雖然您的工程團隊可能會完成此任務，但這需要時間。使用現成的解決方案可以將電子商務資料建模時間縮短數週或數月。

訂單模型

既然您的資料庫中已有客戶，可以購買的產品，您將需要考慮如何設計接訂單流程和資料模型。

下訂單的過程可能如下所示：

1. 客戶在瀏覽時將產品放入購物車。
2. 客戶決定要購買其購物車中的產品。
3. 他們繼續購買訂單。
4. 客戶會收到一封電子郵件收據或確認號碼。

但是，它很少那麼簡單。下訂單可能是欺騙性的棘手，因為有許多活動部件：

• 產品展示
• 活躍的購物車
• 購物車已轉換為訂單
• 帶有確認的最終訂單

如果要檢視訂單放置的簡單資料模型，它可能看起來像這樣：

請注意，ShoppingCartItem表中的每一行都包含產品的“捕獲”價格。當客戶將商品放入購物車時，此時的價格應該“鎖定”嗎？如果是這樣，需要多久？

注意：價格功能是一項業務需求，需要與您的產品所有者進行討論，依此類推，如前面“深入研究：定價”部分所述。

同樣的問題適用於未付款訂單。如果客戶訂購了打折商品，他們是否能夠永遠遵守打折商品的承諾直到付款？還是到期？

訂單資料模型要考慮的其他問題可能包括：

• 您是否在跟蹤訂單分析？
• 如果客戶退回有缺陷的物品會怎樣？
• 您應該在同一資料模型內處理運輸還是具有專用的運輸環境/方案？

考慮到其中一些問題，您可能最終會得到一個看起來更像這樣的資料模型：

在這個更復雜的訂單模型中需要注意的一些事情：

• ShoppingCartItem 現在支援鎖定價格的到期日期。
• ShoppingCartHistory 跟蹤何時新增，刪除專案等。
• 可能會退回一個訂單商品（這仍然無法處理同一產品X個商品中有1個退回的情況）。
• 訂單可能有多次裝運（例如，亞馬遜有時會如何將訂單拆分為多個包裹/裝運）。

本文甚至還沒有涉及使用替代資料儲存方法（如JSON文件或事件溯源eventsourcing）！

結論

為了幫助您瞭解所有零件的裝配方式，以下是所有一起顯示的圖表。我刪除了一些指向Customer表的連結/線，以提高可讀性：

正如我上面提到的，本文甚至還沒有涵蓋許多基本知識，例如付款處理和發票。除了此處介紹的功能之外，您最終可能需要更高階的功能，例如：

• 優惠券程式碼
• 稅收
• 與OAuth提供者，其他零售商或合作伙伴的第三方整合
• 貨運跟蹤通知

如您所見，為電子商務應用程式構建資料模型並不是那麼簡單。深入瞭解實際需求之後，看起來像是一組簡單的資料庫表的東西並不是那麼簡單。