In depth understanding of seven specific ways to enhance code scalability

1  Six principles

There are six design principles in the design pattern ：

Principle of single responsibility ： Do one thing at a time
Li substitution principle ： Subclasses extend the parent
The principle of Dependence Inversion ： Interface oriented programming
Interface isolation principle ： High cohesion and low coupling
Dimitar's law ： Least known principle
Opening and closing principle ： Close changes , Open new

I think the opening and closing principle is the most important of these six principles , The open close principle is an important cornerstone of scalability .

The first reason is that when the requirements change, they should be implemented by adding new code rather than modifying existing code , This ensures code stability , Avoid pulling one hair and moving the whole body .

The second reason is that you can define the code framework in advance , The extension is also based on the framework , It reflects the use of abstraction to build a framework , Extend details with implementation , It ensures stability and flexibility .

The third reason is that the other five principles have different emphases , But both can be included in the opening and closing principle .

The fourth reason is that the twenty-three design modes of the standard finally follow the open and close principle .

Since the principle of opening and closing is so important , How should we follow the opening and closing principle in system design ？

2  Database dimension

2.1  Design type field

We can add two columns in the data table design ：biz_type、biz_sub_type, These two columns are not available at present , You can set a default value first .

biz_type It can refer to business type , Business channel 、 Tenants and so on , In the final analysis, it is used to isolate large business types , Suppose a large business type is added to the follow-up business , Then you can isolate through this field .

biz_sub_type Small businesses can be subdivided in large business types , Make the business more detailed , More flexibility .

2.2  Design extended fields

We can add three columns in the data table design ：extend1、extend2、extend3, You can set it to empty . Extended field storage JSON Type information , Store some extended information 、 Additional information 、 Loose information or information not previously estimated .

The reason for setting three extended fields is to increase isolation , for example extend1 Store order extension information ,extend2 Store product extension information ,extend3 Store marketing extension information .

2.3  Design business binary fields

2.3.1  Demand background

We can add business binary fields in data table design , This field can greatly expand the business ideographic ability . Suppose that users have three roles in the system ： Ordinary users 、 Administrators 、 Super administrator , Now we need to design a user role table to record this kind of information . It is not difficult to design the following scheme ：

It is not difficult to see from the above table , User 1 has the super administrator role , User two has the role of administrator , User three has a normal user role , User four has three roles at the same time . If a new role is added at this time ？ Then add a new field .

2.3.2  Find the problem

There is no problem in the function of table design according to the above field representing a role , The advantage is easy to understand and clear structure , But let's see if there's any problem ？ The author has encountered the following problems ： In a complex business environment, a piece of data may be used in different scenarios , For example, the above data is stored in MySQL database , This data will also be used in the following scenarios ：

Retrieving data needs to synchronize a copy to ES
Business parties use this table through Flink Calculate business indicators
The business party subscribes to this table Binlog Message processing

If the table structure changes , Data sources need to be re docked , The business side also needs to modify the code , So the development cost is very high . Is there any way to avoid such problems ？

2.3.3  Solution

We can use bitmap method , In this way, the same field can represent multiple business meanings . First, design the following data table ,userFlag Fields are not filled in for the time being .

Design bitmaps for each bit Represents a role ：

Use bitmap method to represent the following data table ：

The decimal value of user bitmap is equal to 4：

The decimal value of user 2 bitmap is equal to 2：

The decimal value of user's three bitmaps is equal to 1：

The decimal value of user's four bitmaps is equal to 7：

According to the above analysis, you can fill in the third column of the data sheet ：

2.3.4  Code instance

Don't define enumeration as 1、2、4 Such figures , Instead, it should be defined by displacement , In this way, users can understand the intention of the designer .

// 1 -> 00000001
NORMAL(1, " Ordinary users "),

// 2 -> 00000010
MANAGER(1 << 1, &quot; Administrators &quot;),

// 4 -> 00000100
SUPER(1 << 2, &quot; Super administrator &quot;)

;

private int code;
private String description;

private UserRoleEnum(Integer code, String description) {
 this.code = code;
 this.description = description;
}

public String getDescription() {
 return description;
}

public int getCode() {
 return this.code;
}

Suppose the user already has a normal user role , We need to add an administrator role to it , This is the new role , Correspondingly, there are delete role and query role , These operations require bit operations , See code Notes for details .

// 1 -> 00000001
NORMAL(1, " Ordinary users "),

// 2 -> 00000010
MANAGER(1 << 1, &quot; Administrators &quot;),

// 4 -> 00000100
SUPER(1 << 2, &quot; Super administrator &quot;)

;

//  New role  ->  Bit or operation
// oldRole -> 00000001 ->  Ordinary users
// addRole -> 00000010 ->  New administrator
// newRole -> 00000011 ->  Ordinary users and administrators
public static Integer addRole(Integer oldRole, Integer addRole) {
 return oldRole | addRole;
}

//  Delete the role  ->  Bit exclusive or operation
// oldRole -> 00000011 ->  Ordinary users and administrators
// delRole -> 00000010 ->  Delete Administrator
// newRole -> 00000001 ->  Ordinary users
public static Integer removeRole(Integer oldRole, Integer delRole) {
 return oldRole ^ delRole;
}

//  Is there a role  ->  Bit and operation
// allRole -> 00000011 ->  Ordinary users and administrators
// qryRole -> 00000001 ->  Whether there is an administrator role
// resRole -> 00000001 ->  There are normal user roles
public static boolean hasRole(Integer allRole, Integer qryRole) {
 return qryRole == (role & qryRole);
}

private int code;
private String description;

private UserRoleEnum(Integer code, String description) {
 this.code = code;
 this.description = description;
}

public String getDescription() {
 return description;
}

public int getCode() {
 return this.code;
}

public static void main(String[] args) {
 System.out.println(addRole(1, 2));
 System.out.println(removeRole(3, 1));
 System.out.println(hasRole(3, 1));
}

Suppose that in the operation background query interface , You need to query user data with normal user roles , You can use the following SQL sentence ：

select * from user_role where (user_flag & 1) = user_flag;
select * from user_role where (user_flag & b'0001') = user_flag;

We can also use MyBatis sentence ：

<select id=&quot;selectByUserRole&quot; resultMap=&quot;BaseResultMap&quot; parameterType=&quot;java.util.Map&quot;>
 select * from user_role 
 where user_flag & #{userFlag} = #{userFlag}
</select>

<select id=&quot;selectByUserIdAndRole&quot; resultMap=&quot;BaseResultMap&quot; parameterType=&quot;java.util.Map&quot;>
 select * from user_role 
 where id = #{userId} and user_flag & #{userFlag} = #{userFlag}
</select>

3  Interface dimension

3.1  Design type input

The input parameters of the interface must be of design type , Can be associated with the database biz_type、biz_sub_type Corresponding , You can also customize the final translation of the type to correspond to the database type .

If you don't distinguish types at first , You can set it to the default value first , But its core idea is that input parameters must be distinguished by type .

public class OrderDTO {
 private Integer bizType;
 private Integer bizSubType;
 private Long amount;
 private String goodsId;
}

public Response<String> createOrder(OrderDTO order);

3.2  The design is loosely incorporated

Interface input parameters can be designed Map Type loose parameter , The disadvantage of loose parameters is weak ideographic ability , The advantage is flexibility , Parameters can be added at a lower cost .

public class OrderDTO {
 private Integer bizType;
 private Integer bizSubType;
 private Long amount;
 private String goodsId;
 private Map<String, String> params;
}

public Response<String> createOrder(OrderDTO order);

3.3  Design interface version number

The external interface needs the design version number , For the same interface, external businesses are allowed to gradually switch to the new version , New and old interfaces will coexist for a period of time , Distinguish by version number .

/order/1.0/createOrder
/order/1.1/createOrder

3.4  Design vertically and horizontally

Let's analyze an order placing scenario ： The current is ABC Three order types ：A Order price 9 fold , The maximum weight of logistics cannot exceed 9 kg , Refund not supported .B Order price 8 fold , The maximum weight of logistics cannot exceed 8 kg , Support refund .C Order price 7 fold , The maximum weight of logistics cannot exceed 7 kg , Support refund . It's not difficult to write code plainly according to the literal meaning of the requirements .

@Resource
private OrderMapper orderMapper;

@Override
public void createOrder(OrderBO orderBO) {
 if (null == orderBO) {
 throw new RuntimeException(" Parameter exception ");
 }
 if (OrderTypeEnum.isNotValid(orderBO.getType())) {
 throw new RuntimeException(" Parameter exception ");
 }
 // A Type order
 if (OrderTypeEnum.A_TYPE.getCode().equals(orderBO.getType())) {
 orderBO.setPrice(orderBO.getPrice() * 0.9);
 if (orderBO.getWeight() > 9) {
 throw new RuntimeException(" Exceeding the maximum weight of logistics ");
 }
 orderBO.setRefundSupport(Boolean.FALSE);
 }
 // B Type order
 else if (OrderTypeEnum.B_TYPE.getCode().equals(orderBO.getType())) {
 orderBO.setPrice(orderBO.getPrice() * 0.8);
 if (orderBO.getWeight() > 8) {
 throw new RuntimeException(" Exceeding the maximum weight of logistics ");
 }
 orderBO.setRefundSupport(Boolean.TRUE);
 }
 // C Type order
 else if (OrderTypeEnum.C_TYPE.getCode().equals(orderBO.getType())) {
 orderBO.setPrice(orderBO.getPrice() * 0.7);
 if (orderBO.getWeight() > 7) {
 throw new RuntimeException(" Exceeding the maximum weight of logistics ");
 }
 orderBO.setRefundSupport(Boolean.TRUE);
 }
 //  Save the data
 OrderDO orderDO = new OrderDO();
 BeanUtils.copyProperties(orderBO, orderDO);
 orderMapper.insert(orderDO);
}

The above code can fully realize the business requirements from the function , But programmers should not only meet the function , We also need to think about the maintainability of the code . If you add an order type , Or add an order attribute processing logic , Then we need to add code to the above logic , If handled carelessly, the original logic will be affected .

How to change the straightforward way of thinking ？ This requires adding vertical and horizontal dimensions to the problem analysis , I choose to use the analytical matrix method , Among them, the vertical represents the strategy , Horizontal represents the scene ：

3.4.1  Isolate vertically

The vertical dimension represents the strategy , Different strategies should be isolated in logic and business , This example includes preferential policies 、 Logistics strategy and refund strategy , Strategies as abstractions , Different order types extend this abstraction , The strategy mode is very suitable for this scenario . This paper analyzes the preferential policies in detail , Logistics strategy and refund strategy are the same .

//  Preferential policies public interface DiscountStrategy {public void discount(OrderBO orderBO);}

// A Type preferential policy @Componentpublic class TypeADiscountStrategy implements DiscountStrategy {

@Override
public void discount(OrderBO orderBO) {
 orderBO.setPrice(orderBO.getPrice() * 0.9);
}

// B Type preferential policy @Componentpublic class TypeBDiscountStrategy implements DiscountStrategy {

@Override
public void discount(OrderBO orderBO) {
 orderBO.setPrice(orderBO.getPrice() * 0.8);
}

// C Type preferential policy @Componentpublic class TypeCDiscountStrategy implements DiscountStrategy {

@Override
public void discount(OrderBO orderBO) {
 orderBO.setPrice(orderBO.getPrice() * 0.7);
}

//  Preferential strategy factory @Componentpublic class DiscountStrategyFactory implements InitializingBean {private Map<String, DiscountStrategy> strategyMap = new HashMap<>();

@Resource
private TypeADiscountStrategy typeADiscountStrategy;
@Resource
private TypeBDiscountStrategy typeBDiscountStrategy;
@Resource
private TypeCDiscountStrategy typeCDiscountStrategy;

public DiscountStrategy getStrategy(String type) {
 return strategyMap.get(type);
}

@Override
public void afterPropertiesSet() throws Exception {
 strategyMap.put(OrderTypeEnum.A_TYPE.getCode(), typeADiscountStrategy);
 strategyMap.put(OrderTypeEnum.B_TYPE.getCode(), typeBDiscountStrategy);
 strategyMap.put(OrderTypeEnum.C_TYPE.getCode(), typeCDiscountStrategy);
}

//  Preferential strategy implementation @Componentpublic class DiscountStrategyExecutor {private DiscountStrategyFactory discountStrategyFactory;

public void discount(OrderBO orderBO) {
 DiscountStrategy discountStrategy = discountStrategyFactory.getStrategy(orderBO.getType());
 if (null == discountStrategy) {
 throw new RuntimeException(" No preferential strategy ");
 }
 discountStrategy.discount(orderBO);
}

3.4.2  Arrange horizontally

The horizontal dimension represents the scene , In a broad sense, an order type can be regarded as a business scenario , Concatenate independent strategies in the scenario , The template method design pattern is suitable for this scenario .

Template method pattern generally uses abstract classes to define algorithm skeleton , At the same time, define some abstract methods , These abstract methods are deferred to subclass implementation , Such subclasses not only abide by the algorithm skeleton convention , Also implemented its own algorithm . It guarantees both the statute and flexibility , This is to build a framework with abstraction , Extend details with implementation .

//  Create order service public interface CreateOrderService {public void createOrder(OrderBO orderBO);}

//  Abstract create order process public abstract class AbstractCreateOrderFlow {

@Resource
private OrderMapper orderMapper;

public void createOrder(OrderBO orderBO) {
 //  Parameter checking
 if (null == orderBO) {
 throw new RuntimeException(" Parameter exception ");
 }
 if (OrderTypeEnum.isNotValid(orderBO.getType())) {
 throw new RuntimeException(" Parameter exception ");
 }
 //  Calculate the discount
 discount(orderBO);
 //  Calculated weight
 weighing(orderBO);
 //  Refund support
 supportRefund(orderBO);
 //  Save the data
 OrderDO orderDO = new OrderDO();
 BeanUtils.copyProperties(orderBO, orderDO);
 orderMapper.insert(orderDO);
}

public abstract void discount(OrderBO orderBO);

public abstract void weighing(OrderBO orderBO);

public abstract void supportRefund(OrderBO orderBO);

//  Realize the order creation process @Servicepublic class CreateOrderFlow extends AbstractCreateOrderFlow {

@Resource
private DiscountStrategyExecutor discountStrategyExecutor;
@Resource
private ExpressStrategyExecutor expressStrategyExecutor;
@Resource
private RefundStrategyExecutor refundStrategyExecutor;

@Override
public void discount(OrderBO orderBO) {
 discountStrategyExecutor.discount(orderBO);
}

@Override
public void weighing(OrderBO orderBO) {
 expressStrategyExecutor.weighing(orderBO);
}

@Override
public void supportRefund(OrderBO orderBO) {
 refundStrategyExecutor.supportRefund(orderBO);
}

4  Article summary

This article introduces the design type field 、 Design extended fields 、 Design business binary fields 、 Design type input 、 The design is loosely incorporated 、 Design interface version number 、 Vertical and horizontal design these seven ways to increase system scalability , I hope this article can help you .