大多数客户应用标签管理系统 (TMS) 向Storefront 增加额定的标签。增加这些标签以集成到其余零碎，例如搜寻或社交爬虫、剖析解决方案、销售零碎等。应用 TMS 将为应用程序生命周期带来敏捷性，因为无需通过开发周期即可利用更改。
Spartacus 的指标是反对各种 TMS 供应商解决方案。最风行的标签管理器仿佛是 GTM，但咱们不想将架构以及技术实现局限于 GTM。此外，CDS 也依赖于相似的概念。
TMS 解决方案能够通过所谓的数据层进行集成。只管不存在官网的数据层规范，但外围准则是雷同的：应用程序将数据推送到地方 JavaScript 对象。
谷歌标签管理器 (GTM) 反对窗口对象上的立体 dataLayer 数组，而 Adobe 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 注入令牌）。
咱们可能须要思考事件无效负载。事件无效负载能够为事件保留一些（元）数据。这对于事件零碎十分有用且高效，因而事件订阅者不须要从头开始收集所有数据。