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

如果在线销售产品是您业务的核心部分，那么您需要构建可扩展，灵活且快速的电子商务数据模型。诸如Shopify和BigCommerce之类的大多数现成供应商都是为每月销售几百万美元订单的小型商店而建，因此许多从事大规模工作的电子商务零售商开始研究创建定制解决方案。

本文将研究您自己开始构建此基础结构需要做什么。有哪些方面需要考虑？数据模型可能是什么样？涉及多少工作？

在此过程中，我们将探索一种替代方案：基于API的商务平台，可跨产品目录，定价和订单为您管理数据，而无需将您锁定在一个整体中，而无需重新平台。

注意：本文结尾​​处是电子商务数据模型的完整摘要图。

首先，您需要考虑谁将从您的电子商务应用程序中购买商品。结果如何在数据库中建模客户信息？您可能需要掌握客户的姓名，电子邮件地址等基本信息。是否希望客户能够在系统中创建配置文件？还是每次他们要购买商品时填写表格？

如果希望客户拥有持久的配置文件，则需要建立某种方式让他们登录到您的应用程序。随着更多实际需求的发展，您可能还希望跟踪其登录尝试历史记录和密码历史记录。

您可能还需要考虑您的客户是否属于大型组织。如果可以，他们将如何处理密码重置？他们是否需要单点登录或OAuth支持？

您是否注意到到目前为止显示的任何数据模型中都没有与客户相关的地址？在这些模型中加入客户的地址可能是您的第一选择。但是，大多数客户将拥有多个地址和多种地址，例如帐单和运输。 B2B零售商可能还必须根据他们所支持的仓库和办公室的数量来考虑多个送货地点。

如果帐单和送货地址不同，该怎么办？好吧，您不仅需要做更多的事情，而不仅仅是在客户表中添加额外的列！没那么简单。

如果将付款和运输区域划分为各自具有各自数据库的单独（微）服务，则将帐单和付款地址放入“客户”区域将导致具有“闲谈”服务。构建微服务时，这是众所周知的设计气味。

为避免出现此问题，最好将地址放在需要它们的适当区域/服务中，但这样做会使数据模型变得更加复杂。

避免这种复杂性的一种方法是考虑由API优先软件提供商提供的订单管理系统（OMS）。使用此软件，您可以将OMS集成到数据模型中，而无需花费数月的工程时间。

当您进入商店（面对面或数字化购买）时，看到的第一件事是准备好要购买的产品，并且通常在显示时会考虑您可能的购物方式。

向客户提供这些信息意味着您首先需要跟踪有关产品的大量数据：其价格，历史购买数据等。

让我们来看看为产品目录创建数据模型的“第一枪”：

这是一个产品表，其中包含一些基本信息，例如产品名称，SKU和价格。该产品还链接到另一个表，该表代表与该产品相关联的各种类别。您还可以从策略上将索引和全文搜索添加到“产品”表中，以使站点访问者可以有效地搜索各种产品。

这是一个体面的第一次尝试。但是，要获得更加现实和实用的电子商务产品目录，您需要支持更多要求，例如：

这种模式仍然不够完美，因为它会将您的价格嵌入产品本身，但至少可以让您保持以前的定价历史。

另一个选择是将您的电子商务商店与定价和促销引擎集成，该引擎由API优先为您定价的软件提供商提供。这样，您可以根据用户的意图，位置，购物车或订单历史记录向不同的用户推出不同的价格。

尽管更复杂的产品数据模型在同一张表中仍具有产品价格，但这在真正的大规模应用中可能不是最好的选择。

考虑到您的组织有多个部门，例如库存/仓库，销售，市场营销，客户支持等。您可能拥有专用的系统，使销售商可以更改商品的价格，因为他们是确定商品价格的专家。卖。与考虑客户帐单和送货地址的注意事项类似，如果我们将价格留在核心产品表中，则会导致跨边界/服务沟通。

因此，您可能希望将产品价格存储在销售部门拥有的数据存储下。但是请不要忘记，尚未考虑多种不同的“价格”，包括：

在组织结构的背景下处理所有这些问题将需要对数据模型进行更多的探索和增加复杂性。虽然您的工程团队可能会完成此任务，但这需要时间。使用现成的解决方案可以将电子商务数据建模时间缩短数周或数月。

现在，您的数据库中已有客户，可以购买的产品，您需要考虑如何设计接订单流程和数据模型。

但是，它很少那么简单。下订单可能是欺骗性的棘手，因为有许多活动部件：

如果要查看订单放置的简单数据模型，它可能看起来像这样：

请注意，ShoppingCartItem表中的每一行都包含产品的“捕获”价格。当客户将商品放入购物车时，此时的价格应该“锁定”吗？如果是这样，需要多久？

注意：价格功能是一项业务需求，需要与您的产品所有者进行讨论，以此类推，如＆＃34; Dive Dive：定价＆＃34;中所述。前面的部分。

同样的问题适用于未付款订单。 如果客户订购了打折商品，他们是否能够永远遵守打折商品的承诺直到付款？ 还是到期？ 您应该在同一数据模型内处理运输还是具有专用的运输环境/方案？ 考虑到其中一些问题，您可能最终会得到一个看起来更像这样的数据模型： 可能会退回一个订单商品（这仍然无法处理同一产品X个商品中有1个退回的情况）。 订单可能有多次装运（例如，亚马逊有时会如何将订单拆分为多个包裹/装运）。 本文甚至还没有涉及使用替代数据存储方法（如JSON文档或事件源）的表面！ 为了帮助您了解所有零件的装配方式，以下是所有一起显示的图表。 我删除了一些到Customer表的链接/线，以提高可读性：

就像我在上面提到的，这篇文章甚至还没有涵盖许多基本知识，例如付款处理和发票。 除了此处介绍的功能之外，您最终可能需要更高级的功能，例如： 如您所见，为电子商务应用程序构建数据模型并不是那么简单。 深入了解实际需求之后，看起来像是一组简单的数据库表的东西就变得不那么简单了。 Fabric是一个多合一的商务平台，可帮助您完成本文讨论的所有事情，例如管理客户，订单和货运。 最重要的是，它是基于微服务和API优先的平台。 这意味着您可以选择所需的服务，并将它们与任何其他内部或外部服务无缝集成。 全套电子商务API，可帮助您管理客户，订单等