SAP Spartacus 的 TMS 和 Event Service 实现的关联关系

大多数客户使用标签管理系统 (TMS) 向Storefront 添加额外的标签。添加这些标签以集成到其他系统，例如搜索或社交爬虫、分析解决方案、销售系统等。使用 TMS 将为应用程序生命周期带来敏捷性，因为无需经过开发周期即可应用更改。

Spartacus 的目标是支持各种 TMS 供应商解决方案。最流行的标签管理器似乎是 GTM，但我们不想将架构以及技术实现局限于 GTM。此外，CDS 也依赖于类似的概念。

TMS 解决方案可以通过所谓的数据层进行集成。尽管不存在官方的数据层标准，但核心原则是相同的：应用程序将数据推送到中央 JavaScript 对象。

谷歌标签管理器 (GTM) 支持窗口对象上的平面 dataLayer 数组，而 Adob​​e Launch 是由更复杂的 JavaScript 对象驱动的在窗口对象上调用 digitalData。这两种解决方案似乎都没有提供 API，因此我们不得不直接操作这些全局 JSO。

将 Spartacus 与多个标签管理器集成的高级架构如下图所示。 该示例描述了与 GTM 的集成，但其他标签管理器可以以类似的方式集成。

event service

ngrx action 是事件系统的重要来源，典型的例子就是 Spartacus 购物车组件里对 EventService 的使用。感谢 Spartacus 中的通用事件系统，开发人员可以在其中轻松观察事件。

为了与现有的 ngrx action 解耦，我们将 ngrx action 在底层映射到公共 EventActions。 EventActions 很可能会成为 Spartacus 中的标准，而不是低级别的 ngrx action. 这主要是因为我们将来可能会考虑 sunset掉 Spartacus 中的 ngrx 实现。

虽然 Store 中有大量可用的 (ngrx) 操作，但这些操作主要由来自后端的数据集成驱动。还有许多其他事件也可以考虑在内，例如路由器事件、滚动事件、鼠标交互等。虽然我们可以从简单的 mvp 开始映射现有的存储操作，但设计不应仅限于单一事件源。可以使用多个 EventService（我们可以使用多个 EventService 注入令牌）。

我们可能需要考虑事件有效负载。事件有效负载可以为事件保留一些（元）数据。这对于事件系统非常有用且高效，因此事件订阅者不需要从头开始收集所有数据。