theme: fancy
highlight: github.css
Copy the code

Once we have a business system requirement, one step before we develop the service interface is to do a domain model analysis of it to extract the various real or required domain objects that the business system involves and identify their relationships. For some business systems, completing CRUD operations on these domain objects and changing the composition of their relationships can support most of the business requirements.

When we outline the design, how to do the interface design, how to make the interface structure clear, according to the RESTful specifications to return the need to present the resource structure, and some business behavior or resource shielding details are not exposed.

E-commerce commodity prices

Requirements: There are different pricing strategies for different scenarios

  • Members need to support member level discount rate (administrator can bind discount rate to member role according to actual business)

  • For customers and stores, the need to support level of prices, meaning each minimum order goods there is a fixed more than 10 (tentative) price, then customer need to need to specify a particular price levels, and one tenant can set below to open the price level, we have 10 commercial grade system, and user can set the range of 1-10 of this

  • Separate pricing needs to be designed for an account

  • Stores can choose to order according to the benchmark supply price, which is a unified price

  • Price Adjustment sheet (Special requirement)

Database model

The resulting database model is as follows:

  • T_customer_level_price Customer level price
  • T_price_level Price level
  • T_member_discount Basic member discount rate
  • T_member_level_price Member price
  • T_customer_single_price Customer pricing separately
  • T_supplier_price Base supply price
  • T_pricing_relation Relation between level price and customer, and pricing mode

Interfaces presented according to the database design

The problem summary

  1. First we need to abstract the price model. In the final analysis, the price system is a pricing record. There are two very important information in this pricing record. One is the commodity being priced, and the other is the effect on whom? As for goods, we don’t need to abstract any more, but the goods here are specific to a sku-ID + multi-ID; We can use target to describe who is acting on who here, and then some people might ask, the demand is to fix a certain strategy and only use a certain pricing strategy, such as discount rate, which will only be used by members, in fact, this is the problem, we don’t have to limit the discount and member binding relationship

  2. We analyze the pricing model and specific pricing model, the relationship between the demand for the above as long as the need of new stores and customer need the option pricing model to determine the stores or the customer is using a benchmark pricing GongYingJia or grade, but the domain model, pricing model more should control target pricing model, so the pricing model should not only control of stores and customers, And you can choose one of the four strategies, but not one of them

  3. You cannot put two different models of pricing strategy and pricing hierarchy on a single database table. In this way, the responsibilities are not single (there is a problem here, whether our benchmark supply price should be based on the commodity base price). Summary: We support four pricing models altogether: They are benchmark supply pricing, level price matching (a product has a fixed number of prices, and customers use a certain price), target (the target may be customers, members, or stores) level discount rate, and target separate pricing, and we have a pricing model to determine the pricing strategy of this target

The design steps

  1. Organize key resources according to the data model

2. Organize the resource relationship diagram

3. Define the noun

4. Design interfaces

Organizational (management) Dimensions:

Pricing objective dimension: (Type is an enumeration value: **organization, organization-grade, member, member-grade) **

Unit commodity dimension: