构建可扩展的电子商务数据模型

如果在线销售产品是您业务的核心部分，那么您需要构建一个可扩展、灵活且快速的电商数据模型。大多数现成的服务提供商（例如 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 文档或事件源）的表面！

结论

为了帮助您理解所有部分是如何组合在一起的，以下是所有图表的汇总。为了提高可读性，我删除了指向“客户”表的一些链接/线条：

正如我上面提到的，本文甚至还没有涵盖付款处理和发票等许多基础知识。除了这里介绍的功能之外，您最终可能还需要更多高级功能，例如：

• 优惠券代码
• 税收
• 与 OAuth 提供商、其他零售商或合作伙伴的第三方集成
• 货运追踪通知

显而易见，为电商应用构建数据模型并非易事。乍一看，一组简单的数据库表在实际需求中并不那么简单。

还有另一种方法

如果您可以拥有更多这样的即用型能力，那会怎样？

Fabric是一个一体化商务平台，可帮助您完成本文讨论的所有功能，例如管理客户、订单和发货。最重要的是，它是一个基于微服务且 API 优先的平台。这意味着您可以选择所需的服务，并将其与任何其他内部或外部服务无缝集成。

从高层次来看，Fabric 平台包括：

• 全套电子商务 API，帮助您管理客户、订单等
• 帮助您批量加载现有 SKU 的工具
• 一种利用客户行为提供定制促销和定价的分析工具
• 订单管理工具可帮助您预测库存履行情况并自动化付款处理
• 还有更多！

如果这些听起来像您的电子商务应用程序可能需要的功能，请查看 Fabric 。