如果在线销售产品是您业务的核心部分，那么您需要构建可扩展，灵活且快速的电子商务数据模型。诸如Shopify和BigCommerce之类的大多数现成供应商都是为每月销售几百万美元订单的小型商店而建，因此许多从事大规模工作的电子商务零售商开始研究创建定制解决方案。
本文将研究您自己开始构建此基础结构需要做什么。有哪些方面需要考虑？数据模型可能是什么样？涉及多少工作？
在此过程中，我们将探索替代方案：基于API的商务平台，可跨产品目录，定价和订单为您管理数据，而无需将您锁定在一个整体中，而无需重新平台。
客户
首先，您需要考虑谁将从您的电子商务应用程序中购买商品。结果如何在数据库中建模客户信息？您可能需要基本信息，例如客户的姓名，电子邮件地址等。是否希望客户能够在系统中创建配置文件？还是每次他们想购买东西时填写表格？
刚开始时，基本模型可能如下所示：
如果希望客户拥有持久的配置文件，则需要建立某种方式让他们登录到您的应用程序。随着更多实际需求的发展，您可能还希望跟踪其登录尝试历史记录和密码历史记录。
您可能还需要考虑您的客户是否属于大型组织。如果可以，他们将如何处理密码重置？他们是否需要单点登录或OAuth支持？
深入探讨：地址
您是否注意到到目前为止显示的任何数据模型中都没有与客户绑定的地址？将客户的地址作为这些模型的一部分可能是您的第一个倾向。然而，大多数客户将有多个地址和多种类的地址，如付款和发货。B2B零售商可能还必须根据他们所支持的仓库和办公室的数量来考虑多个送货地点。
如果帐单和送货地址不同，该怎么办？好吧，您需要做的不仅仅是在Customer表中添加额外的列！没那么简单。
那么，存储帐单地址如何影响应用程序的可伸缩性？
如果将付款和运输区域划分为各自具有各自数据库的单独的（微）服务，则将帐单和付款地址放入该Customer区域将导致具有“聊天”服务。构建微服务时，这是众所周知的设计气味。
为避免出现此问题，最好将地址放在需要它们的适当区域/服务中，但这样做会使数据模型变得更加复杂。
避免这种复杂性的一种方法是考虑由API优先软件提供商提供的订单管理系统（OMS）。使用此软件，您可以将OMS集成到数据模型中，而无需花费数月的工程时间。
产品和目录
当您进入商店（面对面或数字化购买）时，看到的第一件事是准备好要购买的产品，并且通常在显示时会考虑您可能的购物方式。
对于电子商务Web应用程序，您可能需要突出显示以下内容：
- 畅销产品
- 热门产品
- 新产品
- 通过搜索条件浏览产品的能力
向客户提供这些信息意味着您首先需要跟踪有关产品的大量数据：其价格，历史购买数据等。
让我们来看看为产品目录创建数据模型的“第一枪”：
这是Product一张包含一些基本信息的表格，例如产品名称，SKU和价格。该产品还链接到另一个表，该表代表与该产品相关联的各种类别。您也可以策略性地在Product表中添加索引和全文搜索，以使站点访问者能够有效地搜索各种产品。
这是一个体面的第一次尝试。但是，要获得更加现实和实用的电子商务产品目录，您需要支持更多要求，例如：
- 跟踪定价历史记录，以便站点管理员可以分析产品定价趋势
- 支持相关产品以显示在产品页面上
- 合并产品供应商，以便客户可以查看单个供应商/公司出售的所有产品
为了解决这些额外的需求，您可能会得到以下数据模型：
该模型仍然不完美，因为它会将您的价格嵌入到产品本身中，但是至少它可以让您保持以前的定价历史。
另一个选择是将您的电子商务商店与定价和促销引擎集成，该引擎由API优先为您定价的软件提供商提供。这样，您可以根据用户的意图，位置，购物车或订单历史记录向不同的用户推出不同的价格。
定价模型
尽管更复杂的产品数据模型在同一张表中仍具有产品价格，但这在真正的大规模应用中可能不是最好的选择。
考虑到您的组织有多个部门，例如库存/仓库，销售，市场营销，客户支持等。您可能拥有专用的系统，使销售商可以更改商品的价格，因为他们是确定商品价格的专家。如果我们将价格留在核心Product表中，这将导致跨边界/服务/跨有界上下文的通信。
因此，您可能希望将产品价格存储在销售部门拥有的数据存储下。但是请不要忘记，尚未考虑多种不同的“价格”，包括：
- 向供应商购买库存时的价格（成本）
- 客户销售价
- 折扣价
- 厂商建议零售价
在组织结构的背景下处理所有这些问题将需要对数据模型进行更多的探索和增加复杂性。虽然您的工程团队可能会完成此任务，但这需要时间。使用现成的解决方案可以将电子商务数据建模时间缩短数周或数月。
订单模型
既然您的数据库中已有客户，可以购买的产品，您将需要考虑如何设计接订单流程和数据模型。
下订单的过程可能如下所示：
- 客户在浏览时将产品放入购物车。
- 客户决定要购买其购物车中的产品。
- 他们继续购买订单。
- 客户会收到一封电子邮件收据或确认号码。
但是，它很少那么简单。下订单可能是欺骗性的棘手，因为有许多活动部件：
- 产品展示
- 活跃的购物车
- 购物车已转换为订单
- 带有确认的最终订单
如果要查看订单放置的简单数据模型，它可能看起来像这样：
请注意，ShoppingCartItem表中的每一行都包含产品的“捕获”价格。当客户将商品放入购物车时，此时的价格应该“锁定”吗？如果是这样，需要多久？
注意：价格功能是一项业务需求，需要与您的产品所有者进行讨论，依此类推，如前面“深入研究：定价”部分所述。
同样的问题适用于未付款订单。如果客户订购了打折商品，他们是否能够永远遵守打折商品的承诺直到付款？还是到期？
订单数据模型要考虑的其他问题可能包括：
- 您是否在跟踪订单分析？
- 如果客户退回有缺陷的物品会怎样？
- 您应该在同一数据模型内处理运输还是具有专用的运输环境/方案？
考虑到其中一些问题，您可能最终会得到一个看起来更像这样的数据模型：
在这个更复杂的订单模型中需要注意的一些事情：
- ShoppingCartItem 现在支持锁定价格的到期日期。
- ShoppingCartHistory 跟踪何时添加，删除项目等。
- 可能会退回一个订单商品（这仍然无法处理同一产品X个商品中有1个退回的情况）。
- 订单可能有多次装运（例如，亚马逊有时会如何将订单拆分为多个包裹/装运）。
本文甚至还没有涉及使用替代数据存储方法（如JSON文档或事件溯源eventsourcing）！
结论
为了帮助您了解所有零件的装配方式，以下是所有一起显示的图表。我删除了一些指向Customer表的链接/线，以提高可读性：
正如我上面提到的，本文甚至还没有涵盖许多基本知识，例如付款处理和发票。除了此处介绍的功能之外，您最终可能需要更高级的功能，例如：
- 优惠券代码
- 税收
- 与OAuth提供者，其他零售商或合作伙伴的第三方集成
- 货运跟踪通知
如您所见，为电子商务应用程序构建数据模型并不是那么简单。深入了解实际需求之后，看起来像是一组简单的数据库表的东西并不是那么简单。