结算体系需求串联多个体系领域才能保证结算事务的完结

本文首要讨论的是电商作业生意结算体系的规划思路，希望借此内容同咱们进行交流。

结算体系需求串联多个体系领域才能保证结算事务的完结，这个串联过程并非无序和随性，咱们需求考虑怎么串联才能达到理想的效果，以保证结算事务有序、精确、高效的履行。

这就需求咱们考虑结算事务中所涉及一切服务的履行必要性、优先级和依靠关系。

例如咱们将【产品营促销信息服务】先于【产品信息服务】，这显然是不合理，产品的有效性都没确认的情况下直接去确认营促销活动这是无法保证活动的可用性的。

因而咱们需求明晰结算事务的依靠关系和次序，以保证咱们可以判别哪些体系服务是必要的，哪些体系服务是高优先级的，对其进行区分和简略排序。

如下图：

5. 整理结算体系交互时序图

结算所依靠的体系服务必要性和优先级开始承认完结，到这步还不行，由于仍是不能明晰的表达详细交互次序和交互的核心内容究竟是什么？

这就需求咱们进一步整理结算体系的作业流程图，这儿可以用于整理的东西和流程类型很多，我个人一般喜欢用时序图来表达。在整理流程的过程中有几个点咱们必须明晰：

1. 明晰参加交互的体系（经过“辨认结算事务形状及场景”&“笼统结算所需服务能力”&“区分结算服务至对应体系”已明晰）。
2. 明晰参加交互体系的作业责任（经过“区分结算服务至对应体系”已明晰）。
3. 明晰参加交互体系所承担责任是否必要条件，以确认反常时是否终止结算（经过“整理结算上下游依靠次序”已明晰）。

后续咱们需求做的就是结合实践的结算事务形状进行体系的的串联，串联过程中咱们需求根据依靠优先级保证串联的流程尽量的简略、高效，以尽量少的交互，保证结算高效、精确的完结作业。

一般情况咱们会以【商家】>【用户】>【产品】>【库存】>【营促销】>【履约】>【计价】>【订单】这样的次序来串联（可根据结算事务的特性调整次序）。并明晰每一步交互的内容，以及对内容的反馈和根本处理。

如下图，这儿仅是示例各行各业需求根据本身结算事务来处理：

6. 确认结算数据承载模型

结算体系在一次买卖过程中，承接了不同体系给到的买卖数据，这些买卖数据既要作为上下游串联的参数，又需求作为买卖的结果数据提供给前端进行处理和展现。所以关于结算数据，结算体系用什么样的模型去承载就至关重要。

由于结算体系几乎是不会使用到DB存储数据（考虑实时性和安全性），但数据需求提供给事务展现及订单体系落库。因而需求结合事务层展现的要求和订单体系落库数据的要求去规划结算体系的模型。

• 事务层：一般会分【结算维度】数据和【产品维度】数据展现给到用户，以便用户可以快速、明晰的承认自己购买的产品（产品维度）、单价价格（产品维度）、活动（产品维度）、数量（产品维度）、配送信息（结算维度）、金额信息（结算维度（销售总金额、优惠总金额、敷衍总金额、实付总金额……）），以促使快速、安全的完结买卖。
• 订单体系：为了后续订单数据使用及办理的规范性，一般会要求落单的数据区分为【订单维度】、【产品维度】、【活动信息】、【买家信息】、【卖家信息】…

经过以上两者的诉求，可将结算体系的数据模型一般笼统为三个层级【结算维度】、【订单维度】和【产品维度】每个维度可根据实践的事务形状承载不同的信息。