终于写到 Jerry 目前正在做的开发工作了。
2015 年的时候，那时 Jerry 曾经做了一年多的 SAP UI5 开发，想进一步精进本人的开发技能，就申请了一个位于德国 Walldorf 总部的 UI5 Extensibility 开发的 Fellowship Program，为期 6 个月。Jerry 发了简历给接管 Fellowship 的团队老板，很快收到回复，团队老板对我的简历很感兴趣，然而示意这个 Program 没有 Relocation Budget，如果我过来，在 Walldorf 的住宿得我本人掏钱解决。因为这不是商务出差，因而也不会有专门的共事帮我在当地租房。想到这一系列的麻烦，最初我只能放弃。
没想到五年之后，我再次取得了另一个纯前端的开发机会，SAP Spartacus.
什么是 Spartacus？Spartacus 是 SAP Commerce Cloud 的 Storefront(电商铺面)利用，基于 Angular 开发而成。
借助 SPA(Single-Page-Application)和 PWA(Progressive-Web-Application)个性的反对，Spartacus 可能提供近似原生利用的用户体验，同时具备高度的可配置性和可扩展性。
先看看 Spartacus 长什么样。对于国内习惯了网购的敌人来说，无需任何培训就能毫无艰难地应用 Spartacus 进行购物下单，这些操作流程咱们曾经相熟得不能再相熟了。
浏览商品，增加到购物车，领取。
可能大家会感觉下面截图的界面比拟奢侈，不够好看？后面曾经提到，Spartacus 具备高度的可配置型和可扩展性，SAP 客户能够基于 Spartacus 开发出具备本人举世无双格调的 Storefront 利用。
一个胜利案例就是，乐高的在线销售 Storefront.
Spartacus 最显著的两个特点：
- 开源(https://github.com/SAP/sparta…
- 以库文件的模式公布
也就是说，客户只须要新建一个 Angular 利用，在 package.json 里增加对 SAP Spartacus 库文件的依赖，就能够应用上图所示的 Spartacus Core 和 UI Component，开发满足本人理论需要的 Storefront 了。
下图就是 Angular 利用中的 package.json 文件中导入 Spartacus 的四个依赖库文件的形式：
客户采纳这种形式开发而成的 Storefront 利用，其自开发代码 (下图淡黄色矩形框所示) 是降级平安的，即自开发代码不会因为 Spartacus 库文件的版本升级而被笼罩掉。
Spartacus 是一个仍在继续开发的我的项目，目前最新的版本是 3.0. 通常状况下，每隔 6 个月会进行 Major 版本的更新，比方从 2.0 到 3.0. 每隔 6 周，会进行 Minor 版本的更新，比方从 2.0 到 2.1.
对 SAP Commerce Cloud 有所理解的敌人们都晓得，Hybris 以前还有一个基于 JSP 的 Accelerator，也能提供浏览店铺商品，退出购物车，结帐领取的性能，那么为什么 SAP 依然会启动 Spartacus 的开发，并在 2019 年 7 月正式公布了 1.0 版本呢？
我的共事张健 (Zhang Jonathan) 在他的文章 从产品展现页面谈谈 Hybris 的特有概念和设计构造 里给大家介绍过，Commerce Cloud 的前身 Hybris 是一个 monolithic(单体)利用，其中 Storefront 即 Accelerator 实现的技术栈是 JSP + Java，没有前后端拆散的概念。
Accelerator 尽管如张健文章里介绍的那样，具备高度可扩展性，然而也存在一些问题：
因为 monolithic(单体)利用的个性，Accelerator 自身也是 Commerce 平台的一部分，通过 Java 调用经 Facade Layer 作为入口，生产 Service Layer 的服务：
如下图高亮代码所示：
因而，Accelerator 和 Commerce 平台无奈别离进行降级。
另外，SAP 官网明确指出，因为 SAP 以源代码的形式公布 Accelerator，作为施行的模板，因而一旦客户开始了 Storefront 的定制化工作，批改了这些模板的源代码后，就无奈再导入针对当前工作版本的 Accelerator 的 bug fix. 这个情理同 ABAP Netweaver 外面，如果开发人员间接批改了规范代码后，打不了 SAP note 是一样的。
这也就是 SAP 官网上称 Accelerator 为 ”Extendable but not Upgradable” 的起因。
Commerce Accelerator 的这些有余，通过 2019 年诞生的 Spartacus Storefront 失去了补救：
100% API-Driven
Spartacus 和 Commerce 后盾的所有交互均通过 API 实现，Commerce API endpoint 通过环境变量 SPARTACUS_BASE_URL 注入 Spartacus，如下图所示：
Focused Development
应用 Spartacus，SAP Commerce Storefront 开发人员只须要专一于 Angular 开发。前后端拆散之后，Storefront 的开发，不再须要 Accelerator 时代的全栈开发模式。
Continious Delivery
以周为单位的 patch 公布频率，使得继续交付成为可能。同时，客户通过导入 Spartacus 库文件的形式进行 Storefront 的二次开发，其定制化代码和 Spartacus 库文件是独立的实体，能够别离进行降级；Spartacus 和 SAP Commerce 能够别离进行部署，亦可进行各自的降级。
更多对于 SAP Spartacus 的介绍，请参考 openSAP 上的公开课.
要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”:
更多浏览
- 从产品展现页面谈谈 Hybris 的特有概念和设计构造
- 从产品展现页面谈谈 Hybris 系列之二: DTO, Converter 和 Populator
- 从产品展现页面谈谈 Hybris 系列之三：Hybris Service 层介绍