1 background

The fulfillment of an order begins with delivery. The seemingly simple delivery function hides many little secrets behind it.

Shipping business features:

B-side business, the performance requirements are not high, because there are scenarios for batch delivery.
The delivery time is relatively scattered, so the amount of concurrency is not large.
The business is complex, involving the delivery of N order types, and different order types have different business rules.

With the development of the company's business and the increase of order types, the delivery logic without abstraction will inevitably appear behind as the iteration advances. Of course, in the iterative process, it has been optimizing and evolving. As the saying goes, there is no best, only the most reasonable one that meets the current business status.

2 Phase 1 Seller Shipping

At the beginning of the seller's delivery, there are N interfaces. For example, spot single delivery, spot batch delivery, spot fast delivery, app delivery, direct delivery, customized delivery, etc.

The fact that there are so many delivery interfaces is also determined by the business characteristics of our platform. Spot goods means that sellers ship to the platform, and direct delivery means that sellers ship to buyers. Different businesses have different processes. In addition to the problem of multiple interfaces, another problem is logic dispersion. Each interface is an independent logic, and the appearance of a large number of repeated codes greatly increases the cost of maintenance.

A simplified delivery process is as follows:

Parameter check
Some business verification, such as order status, delivery cooling-off period, etc.
Write off seller offers
push state machine
Save order data modification
broadcast shipping message
Issue the storage order
Subscribe to logistics track
……

In the whole process, there are many points that can be optimized. For example, many operations after the order data is updated can be processed asynchronously, which can improve the overall performance of delivery.

Summarize several problems that sellers have in delivery before:

Many external interfaces, difficult to maintain
The delivery business is strongly bound to the order type
The internal logic is scattered, and there is no overall picture of the business
overall performance bias

3 The second stage of the seller's delivery

3.1 Business Transformation

As mentioned earlier, the current shipments are arranged based on the order type classification. The reason for classifying by order type is because there were only order types before, and all businesses were distinguished according to order types. The main reason is that the delivery is not done from the perspective of contract performance, so each additional order type has a certain impact on delivery.

From the perspective of performance, there will be a performance order. There are performance modes on the performance order, currently available in stock, direct delivery, warehouse delivery, virtual, service order, cross-border direct delivery, cross-border spot delivery, and cross-border in-warehouse.

The performance model is a business model for how the goods are delivered from the seller to the buyer. Different models have different business processes. In the scenario where the seller delivers goods, it only focuses on how the goods reach the buyer, not how the goods arrive at the buyer. Need to pay attention to what type of order.

Spot goods

The spot mode means that the seller sends the goods to the platform, and the platform passes the quality inspection/identification and then sends the goods to the buyer. The types of spot orders include ordinary spot, fast spot, fast pre-sale, deposit pre-sale, etc.

straight hair

The direct shipping mode refers to the seller sending the goods directly to the buyer. The order types of direct delivery include brand direct delivery, deposit pre-sale direct delivery, auction direct delivery, crowdfunding direct delivery, blind box direct delivery, etc.

Cangfa

Warehouse delivery mode means that the seller sends the goods to the platform warehouse in advance, and the buyer sends the goods directly from the warehouse after placing the order.

virtual

Virtual mode refers to online fulfillment without express delivery. The types of virtual orders include Xpress Saver, Sanitation Card, Virtual Card Roll, etc.

service order

The service order refers to customized services. The goods need to be sent from the platform to the service provider. After the service provider completes the customized service, it will be sent back to the platform, and then the platform will send it to the buyer.

It can be seen from the division of contract fulfillment modes that each business scenario has an order type, but they are all the same in terms of contract fulfillment methods. The second-stage delivery will arrange the business process according to the contract fulfillment model, without perceiving the type of order, so as to accumulate platform-based capabilities, instead of following the upper-level business that needs to be changed every time. If there is specific business processing for a certain order type, this logic will be placed on the order side.

3.2 Stability modification

In terms of stability, some improvements have also been made. Although delivery is not a link for shopping guides to place orders, it is also a very important node. If there is a problem with the delivery, the status of the order cannot be advanced, and subsequent issues such as closing the order over time will occur. Therefore, the stability must be strictly guaranteed.

If there is a failure in the entire delivery operation, an alarm will be issued immediately. Of course, some normal business verification scenarios will be blocked here, otherwise too many alarms will be meaningless. At the same time, based on the current error code market of the order, the delivery market is also constructed. The number of failed shipments and the reason for the failure can be seen through the market to see if there is any problem.

3.3 Business Perception

As a R&D student, whether it is business R&D or middleware R&D, you need to have a better understanding of the usage of the systems and functions you are responsible for. Building a business market is a very good way to perceive business conditions in real time.

For example, in the delivery scenario, the data we need to perceive is as follows:

total shipments
Shipments of each fulfillment mode, spot xxx, direct delivery xxx, virtual xxx
Shipments of each scenario, App xxx, Merchant background xxx, Open platform xxx
Shipping carrier distribution, SF xxx, JD xxx
Distribution of delivery methods, door-to-door pick-up, self-delivery, ordinary fulfillment (waybill placed on the platform)
……

3.4 Retrofit benefits

The benefits of this transformation are as follows:

Unified delivery interface
- There is only one interface, supporting all seller delivery scenarios;
- Low access cost and simple access method
Unified delivery agreement, supporting simultaneous delivery of multiple waybills and multiple orders
Business arrangement based on the fulfillment model, new order types do not need to be modified
- Improve development efficiency related to follow-up delivery
Perfect business market, error code market

4 Three-stage seller delivery

4.1 What is Business Identity

When we do platform-based business and provide services for multiple businesses at the same time, we need to have an identifier that can distinguish the identity of each business service request, so that we can provide differentiated and personalized services. I understand that this is the business identity.

Just like when a consumer goes to an offline store to consume, the merchant will ask the consumer to apply for a membership card. The membership card has different levels, such as gold card, platinum card and so on. Consumers will bring this card every time they go to the store for consumption. This card is the identity of the consumer, and merchants can also provide consumers with differentiated services based on this card.

4.2 Problems faced by sellers in delivery under contract fulfillment mode

Before building business identities, we deal with differentiated business processes based on the performance model. It’s not that you have to draw a business identity, but at a certain stage, the complexity of the business has to make you change the existing model. To put it bluntly, there is no way to support the changing business. Even if you can support it, the impact of the change will be Relatively large, the range of test regression is relatively wide. Therefore, we need to reflect on what form to solve complex businesses, while supporting the variability of subsequent businesses and reducing the scope of testing. This is the fundamental reason why we build business identities.

The above may be a bit abstract. Let me use a specific example to illustrate the current problems encountered and how to use business identities to solve this problem and how to achieve high scalability.

In the fourth point of this article, the seller's delivery based on the perspective of fulfillment, it has been explained that the latest delivery is based on the fulfillment model for business arrangement. The direct delivery and spot delivery modes are both physical-based fulfillment modes, which need to be delivered by express delivery. But we also have a virtual fulfillment model. Virtual fulfillment does not require express delivery, but online, such as monthly cards, game skins, ticketing (e-tickets) and so on.

As shown below:

Ticketing in the virtual mode currently only supports the form of electronic tickets. In the latest demand, physical tickets need to be supported. Physical tickets are delivered by courier by default. If the purchase time is close to the start of the show, then the courier delivery must not meet the requirements in terms of time. At this time, another method appears, which is on-site ticket collection.

At this point, you can see the figure below. In the virtual mode, there are various business scenarios. When the virtual order needs to go through the express delivery link, the existing business arrangement based on the fulfillment mode cannot support it. If you don't talk about rationality and only realize the requirements, you can only open a new process in the virtual mode to handle the express delivery process. However, the processes related to express delivery are ready-made in the direct delivery and spot delivery modes, and the follow-up maintenance and understanding costs are too high. This is the business expansion problem currently faced by delivery based on the fulfillment mode.

4.3 How to break the business identity and improve scalability

As shown in the figure above: the underlying capabilities are no longer bound to the performance model one by one, but abstracted based on business scenarios. The advantage of this is that these underlying capabilities can be reused, and how to reuse requires abstracting specific business identities.

for example:

Capabilities corresponding to spot general business identities are as follows:
- Waybill number verification required
- Creation of shipment batch orders does not require
- Discount write-off required
- State Machine Spot
The capabilities corresponding to the Spot App business identity are as follows:
- Waybill number verification required
- Creation of shipment batch orders requires
- Discount write-off required
- State Machine Spot
The capabilities corresponding to virtual general service identities are as follows:
- Waybill number verification is not required
- Creation of shipment batch orders does not require
- Discount write-off not required
- state machine virtual
The capabilities corresponding to the identity of the virtual courier service are as follows:
- Waybill number verification required
- Creation of shipment batch orders does not require
- Discount write-off not required
- State Machine Virtual Express

Through the above examples, I believe that everyone understands the role of business identities, abstracts business identities in combination with business, and binds corresponding capabilities to business identities, so that the underlying capabilities can be fully reused.

Of course, the focus here is how to extract the corresponding business identity. The business identity is a result of multi-dimensional aggregation, and it cannot be fabricated casually. Based on the analysis of the seller's delivery scenario, the business differences are reflected in the following points:

Different ends have different logic
- The end here refers to the system used by the seller when delivering goods, such as App, merchant background, open platform docking, etc.
Different fulfillment models have different logic
- The fulfillment mode has been subdivided, including direct delivery, spot delivery, customization, virtual and so on.

Therefore, our business identity is the corresponding terminal + performance model. For those without differences, we can set a general business identity, and then extract them separately if there are differences later. For example, the common stock, which needs to be subdivided is the App stock.

The business identity composed of the above dimensions can satisfy most scenarios, but there are still some scenarios that cannot be satisfied, that is, the scenario where virtual orders are delivered by express delivery. That is to say, I can only recognize that the current business identity is the virtual mode, but I cannot recognize whether the virtual mode is to be delivered by express delivery, to pick up tickets on the spot, or to deliver goods with a certificate.

For this reason, a third dimension is added to form the business identity, so that it can be clear what the current business identity needs to do. Therefore, for virtual business identities, there will be three business identities: virtual universal, virtual express delivery, and virtual on-site.

For business identities, it will also evolve with the business. Maybe in the future, the entire contract fulfillment link will be standardized and provided for multi-service use. At this time, a very important dimension will be added to the business identities: tenants.

4.4 Retrofit benefits

4.4.1 High scalability

In fact, high scalability has already been mentioned above, and the way of orchestrating business identities can easily support the fulfillment of virtual orders by express delivery. There is no need to add if to make strong judgments in the previous logic.

For example, there is a need to intercept the scene of sub-packages (one waybill and multiple packages) during delivery, and only intercept in a certain fulfillment mode. At this time, we can add a basic ability to intercept parent and child parts, which are interception and non-interception respectively.

Then configure interception for business identities that need to be intercepted, and configure no interception for business identities that do not need to be intercepted, so that only specified scenarios will use the ability to intercept parent and child parts. If other modes later also support interception, you can directly change the configuration without changing the underlying business code.

The premise of high scalability is good abstraction and layering. The overall business architecture of delivery is shown in the following figure:

4.4.2 Low cost of testing

The low cost of testing is mainly reflected in the fact that the scope of changes is controllable, because specific capabilities are abstracted throughout the delivery process. For example, if you change the A ability, and the A ability only works in the virtual mode, then the test only needs to return to the process of the virtual mode.

In terms of the above-mentioned interception scenario of mother and child parts, it is only necessary to test the spot mode, and the old logic does not need to be looked at, because it is a newly added capability point and will not affect the old business logic at all.

In other words, under the development of business, a new business identity has emerged, but the capabilities corresponding to this business identity are all existing capabilities, but some capabilities are not needed. At this time, only two places need to be changed, one is the business The configuration of the identity correspondence capability, the other is the logic of calculating the business identity, which can determine that the current request is the new business identity based on certain conditions. At this time, the test only needs a simple verification, and the underlying capabilities are already in use. The difference lies in the arrangement.

Whether it's new additions, revisions, or rearrangements. Can clearly know the current adjustment range, so the cost of testing is naturally relatively low. It is no longer necessary to change a few lines of code as before, not knowing what scenarios are used, and then return to it all.

5 Future Prospects

5.1 Continuous improvement of underlying capabilities

At present, the number of underlying capabilities in the delivery scenario is not large, and there will still be simple if judgment logic in some scenarios. At present, these scenarios are not particularly complicated. With the development of business and changes in rules, when these logics become more and more complex, it is necessary to continue to extract atomic-level capabilities.

The extraction of capabilities and the abstraction of business identities are a long process, and there is no static situation, only a process of gradual evolution and optimization.

5.2 Visual orchestration of business identities

Visual orchestration is not an important part in the early stage. As the underlying capabilities become more and more abundant, and business rules become more and more frequently changed, it becomes very important whether the R&D side can deliver quickly. Through visual orchestration, you can quickly adjust business processes and add a complete set of new processes without relying on code transformation and version release. Of course, this also requires a lot of corresponding mechanisms to ensure stability. After all, code changes are released after an iterative test each time. This kind of dynamic change also requires a corresponding grayscale mechanism.

5.3 Expand the scope of application of business identity

The business identity is currently only implemented in the delivery scenario of the seller. There are many other platform-based capabilities in contract fulfillment. How to use the platform-based capabilities to support the changing business of the upper layer is the core appeal. Once the business identity is determined, in the entire contract fulfillment link, the overall process arrangement and differentiated processing can be done based on the business identity.

*Text/YJH

This article is an original article of Dewu Technology. For more exciting articles, please see: Dewu Technology Official Website

It is strictly forbidden to reprint without the permission of Dewu Technology, otherwise legal responsibility will be investigated according to law!

E-commerce Order Fulfillment - Evolution History of Seller Delivery