共计 940 个字符，预计需要花费 3 分钟才能阅读完成。
大多数客户应用标签管理系统 (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 注入令牌）。
咱们可能须要思考事件无效负载。事件无效负载能够为事件保留一些（元）数据。这对于事件零碎十分有用且高效，因而事件订阅者不须要从头开始收集所有数据。
