SAP Commerce(原Hybris)的一些架构图,持续更新
版本号:v1.00 2020年4月13日
@TOC
模块图
layer chart
类型
类型继承
- At the bottom is the Service layer, which includes fine-grained(细粒的; 精准的) business methods, such as the ones responsible for adding promotions to a cart, or for calculating the total value of the cart. These services expose the data model, which persists in the database.
- On top of the Service layer, there are facades, which implement specific business use-cases, such as adding a product to a cart, placing an order, or searching for a product. The facades expose the Data Transfer Objects (DTOs), which are completely independent from the underlying storage technology. There may be a one-to-one mapping of the model (such as store products), but there may also be a subset of the model, or aggregated models. The DTOs are not always stored in the database. An example of this is the Solr objects, which are stored in the Solr index.
The converters delegate to populators to convert the DTOs back and forth to models. For example, a product that has basic attributes, such as name, title, and description, can also have classification attributes. Therefore, you might have two populators, one for the basic attributes, and one for the classification attributes.
The facade layer, including the DTOs, represents the SAP Commerce OmniCommerce Connect. This is a business API, and the foundation for the web services.
- On the top layer, the Controllers take the DTOs and expose them to the view. This is done using the Spring Model View Controller (MVC), which replaces all the facades, services, and controllers.
出自这里.
ServiceLayer Direct
Here is a comparison of write operations in ServiceLayer Direct and Jalo:
Here is a comparison of read operations in ServiceLayer Direct and Jalo:
core extension
Order extensibility
Service Layer
Model runtime
Model interceptor
Application Context hierarchy
key service
Accelerator架构
请求交互图
文件目录
文件或模块名 | 路径 |
---|---|
chinesepspwechatpayservices | ext-commerce |
alipay | ext-accelerator |
本文来自云栖社区合作伙伴“汪子熙”,了解相关信息可以关注微信公众号"汪子熙"。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Spring Boot 和 Spring Cloud 应用内存如何管理?
Spring Boot 和 Spring Cloud 应用内存如何管理? 在整体应用架构中,非生产环境情况下,一般 1GB 或者 2GB 的 RAM 就足够了。如果我们将这个应用程序划分为 20 或 30 个独立的微服务,那么很难期望 RAM 仍将保持在 1GB 或 2GB 左右。特别是如果我们使用 Spring Cloud 的时候。 首先,准备三个服务,Eureka 服务 + 提供 REST API 的两个简单的微服务,并将微服务注册到 Eureka。此处,不以任何方式限制这些应用程序的内存使用。 提示:Spring Cloud 简单应用的搭建示例:https://www.ictgu.cn/share/6644e468 就像你在下图看到的一样,三个微服务大概占用了电脑 1.5GB 的 RAM 内存。这三个服务是最简单的应用程序,基本没有数据处理量,对于这样的内存消耗量,显然是不理想的。RAM 的最低使用量是用于 Eureka发现服务,最大的用于初始化声明式客户端以调用其他服务的 API。 关于内存使用量如下图 JProfiler 制作的图表。如图所示,内存使用受堆影响,与非堆相比,它...
- 下一篇
从 Python 切换到 Go 的 9 个理由
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 切换到一种新的编程语言通常是一件大事,特别是当团队成员对原始语言有丰富经验时。今年年初, Stream 将其主要编程语言从 Python 切换到了 Go。本文将会解释他们决定从 Python 切换到 Go 的一些原因。 使用 Go 的理由 理由 1:性能 Go 非常快。它的性能接近 Java 或 C。Go 的速度比 Python 快 30 倍。 理由 2:语言本身的性能很重要 对于许多应用程序而言,编程语言只是应用程序和数据库之间的粘合剂。语言本身的性能通常并不重要。 Stream 是一家 API 提供商,它为 500 家公司和超过 2 亿的最终用户提供了反馈基础设施。多年来,我们一直在优化 Cassandra、PostgreSQL、Redis 等软件的性能,但是现在我们已经达到了我们所使用编程语言的极限。 Python 是一门伟大的语言,但是对于序列化 / 反序列化、排序和聚合等示例,它的性能非常差。我们经常会遇到性能问题,Cassandra 花费 1ms 的时间来检索数据,而 Pyt...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS关闭SELinux安全模块
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作