Javashop enterprise-level e-commerce middle platform architecture

In recent years, the concept of Zhongtai has been widely discussed. Should e-commerce companies adopt the structure of Zhongtai? Some are considered from a strategic point of view, and some are considered from the point of view of business needs. Among Javashop 's customers, there is also the need to build a middle-office system. We summarize our experience in implementing the e-commerce middle-office system for our customers and share with you here.

1. What are the problems faced by large enterprises in e-commerce

1. cross-domain

The general business coverage of large enterprises is extensive, and the sub-businesses span multiple fields, resulting in the coexistence of commonality and differentiation of business models. Cross-domain leads to complicated operation experience and process. In the implementation of e-commerce, it is necessary to sort out each sub-business, abstract it, and implement it into software requirements.

2. a center

When faced with complicated sub-businesses, many group enterprises need a center and a set of specifications to integrate the system. To achieve data centralization, core business centralization, interface centralization, standardized unified realization of function reuse, improve efficiency and reduce costs.

3. multi-terminal multi-contact

Following the pace of the Internet era, it realizes WeChat H5/mini program/App/Pc multi-terminal support, and the combination supports enterprise business development.

4. Flexible operation and maintenance

The operation and maintenance of e-commerce marketing itself requires flexibility and change, and the e-commerce business of the enterprise may not be the original familiar field. The operation and maintenance team needs to constantly try "new ways of playing", which requires the system to respond quickly to changes and achieve agile changes.

2. How to Help Enterprise E-commerce Landing Promote the landing of enterprise e-commerce We start from the following three points:

1. Javashop e-commerce center abstracts business center, covering user center, commodity center, order center, marketing center, after-sales center, and payment center. The business center exposes the unified standard service interface within the enterprise, and realizes the respective order business flow through the message bus sub-business.

2. The front-end and back-end separated architecture of the Javashop e-commerce middle platform allows the front-end to flexibly access the business middle-end, and the unified user center enables the front-end to reuse the business middle-end capabilities to achieve flexible response and rapid implementation.

3. The business platform enables enterprises to quickly and repeatedly use the e-commerce system standards and basic capabilities, and can also meet the individual needs of each sub-business department, that is, allowing sub-departments to "fight each other" and form unified data and business center.

3. The overall architecture of Javashop middle platform

infrastructure

At present, large enterprises have their own paas platforms, or private cloud products built or purchased by themselves (such as Tencent, Ali, Qingyun, etc.).

Electronic business platform

  1. On top of the infrastructure, we provide a set of standard e-commerce platform, including user center, commodity center, order center, marketing center, after-sales center, payment center, and provide general e-commerce business capability support, such as creating orders, payment etc.
  2. Multi-terminal and multi-touch based on business abstraction
  3. Javashop provides a set of standard e-commerce front-end support: PC, WAP, applet, APP, this part is the general e-commerce logic, customers will customize the front-end according to their own business conditions, provide personalized functions, interactive experience, etc., these Personalization is derived from the personalized needs of the enterprise.

Fourth, the landing preview in the middle stage

Let's take the personalized ticketing sub-business as an example to illustrate the implementation of the middle-office business. As shown in the figure above, the functional process and operation experience of the front-end of the sub-business are abstracted according to the requirements of the sub-business (such as ticketing):

Display the validity period of the ticket, seat status, etc., click to buy directly to the settlement page, and provide a seat selection interface, click the "Confirm Purchase" button to place the order and pay directly.

For the display of general information such as product names and photo albums, the front-end is implemented by calling the "Central-Taiwan Core API". This part of the API is provided by the Central-Taiwan.

For the personalized requirements of the validity period and seat situation, the API of the sub-business needs to be provided. This part is the API that the sub-business needs to develop and provide, and then the front-end integration of the sub-business.

Similarly, if the creation and payment of an order cannot be satisfied by the general API of the middle office, sub-businesses also need to call the core API to complete it together.

Let's take the common order creation and payment as an example to introduce several common centers: member center, commodity center, order center and payment center

Member Centre

The core requirement is to solve the diversity of user sources of group enterprises, such as offline channels, non-e-commerce users, OA users, erp users and so on. The user center needs to solve these users' convenient access to the e-commerce system, facilitate the transformation of SSO (unified authentication), and even form the user center of the entire group.

  • Unified registration api

Sub-services or other system calls can be provided

  • Unified Authentication Mechanism

Token-based identity authentication facilitates access to other systems and implementation of sso

Commodity Center

The core requirement is unified commodity storage and management to facilitate sub-businesses to access commodity data (inventory, index, etc.).

  • commodity base api

It can provide the basic information of the sub-business accessing products (product name, photo album, etc.)

  • fire squad

Can provide sku information for sub-business to access products

  • in stock

Provide sub-business access to commodity inventory

Order Center

  • The unified order creation interface does not depend on the shopping cart, which is convenient for other sub-businesses to call.

  • Order query interface

  • Order message bus, providing order change messages

payment center

Independent payment center, unified payment interface

  • Independent payment center (configuration, api)

  • Bill-Oriented Payment System

Group-type enterprises have many sub-businesses, but they need a unified payment center to provide unified parameter configuration, unified cash register, and facilitate the management of financial data.

Let's take the scenic ticketing business scenario as a sub-business to illustrate the structure of the payment center:

When a user buys a ticket in a scenic spot, the sub-service in the scenic spot may be triggered to create an order by scanning a code or manually, and then the sub-service guides the customer to the cashier of the sub-service.

When the customer clicks to confirm the payment, check whether the payment can be made in the sub-business (such as whether the inventory lock is successful, etc.). If the payment can be made, call the payment center payment interface to mobilize the payment. The payment center should check whether the order number of this sub-business has been paid. Check whether the bill and the amount are consistent, and then call the third-party payment interface to form the parameters for invoking the payment, return it to the sub-business, and guide the customer to pay.

The customer completes the payment operation at the cashier. When the third-party payment system (Alipay, WeChat, etc.) confirms that the payment is successful, the payment center will be notified. Post-ticketing (manual, machine, etc.).

When the sub-business is refunded, call the payment center refund interface to refund the money to the customer. After the refund is successful, a bill change message will be sent to notify the sub-business.

The payment center also has a bill status query interface for sub-business query status.

Summarize

Based on our sharing above, Javashop Zhongtai System hopes to provide an e-commerce landing solution that can meet the needs of large and medium-sized enterprises. In recent years, discussions and debates about Zhongtai have intensified. Our view is "What suits you is what you do well." ”, you must start from your own business model, not blindly pursuing “popularity”, technology should serve the business, and the architecture of the middle-office approach does provide technology reuse and improve efficiency to a certain extent, but if the enterprise business does not have enough Complex, or the team does not know enough about distributed development and service development, it is recommended not to adopt the middle-desktop solution first. For simple requirements, the traditional and vertical architecture is faster and more flexible. After a period of development, it may be Forcing the team to update the structure, then service-oriented and Zhongtai-oriented is not a bad idea. You are welcome to express your views in the comments section.

Original article by javashop

{{o.name}}
{{m.name}}

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=324079217&siteId=291194637