How to design the changing system requirements

Note: This article refers to "Online Interviewer""Online Interviewer" system requirements change, how do you design it?

I now have a system that takes different actions based on the input parameters of the request.However, this different action is likely to have changes in demand. How would you design this system?

Practical example: There are now multiple third-party channels, and the system requires order attribution for each channel.However, the logic of attribution is likely to change, and the logic of attribution of different channels is not the same. At this time, the logic in the system is relatively complex.

If you could optimize, how would you design?

In the final analysis, the processing logic is relatively complicated, and there are too many if else judgments

Although new requirements come, they can be solved by adding if else

But what you want is a more scalable and maintainable system

Want me to come up with a solution to solve similar problems

Before this, most of the Internet searches on how to solve if else are said to be strategy mode

But I don't feel the same way about the example I gave. Many times I just finished reading it

Actually, in the project, there are still quite a lot of strategy patterns, which may have been used accidentally (after all, interface-oriented programming)

And in my opinion, the strategy pattern is not the key to solving if else

The approach in my project is: Chain of Responsibility Pattern

Extract each process into a Process (which can be understood as a module or node), and then the request will be stuffed into the Context

For example, if a project has been maintained before, it is similar to different channels and different logics

Our approach here is to extract relevant logic into the Process and assign different chains of responsibility to different channels

For example, the chain of responsibility of channel A is: WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcess

The chain of responsibility of channel B is: WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcess

On the basis of the chain of responsibility, "scripts" can be embedded in the code

For example, on SendProcess, there is a built-in script for sending messages (the script can select different operators to send messages).With the "script", changes to the logic can take effect without restarting.

Some people call this set of things a "rule engine".For example, the well-known implementation framework "Drools" in the rule engine can do similar things

Write easy-to-change logic on "scripts" (at least we believe that scripts are separated from the real logic of our application)

(The script here refers to the ruleset, it can be the dsl of Drools, it can be Groovy, it can be aviator, etc.)

At my previous company, Groovy scripts were used.The general implementation logic is: there is a special background to manage the script, and then the script is written to the "distributed configuration center" (refreshed in real time), and the client monitors whether the script stored in the "distributed configuration center" has changed.

If there are changes, recompile and load the script through the Groovy class loader, and finally put it into the Spring container for external use

The system I am currently in charge of is this way to deal with the business of changing and frequently changing requirements (chain of responsibility + rule engine)

As far as I know, our game business has done more things in the "chain of responsibility"

The "chain of responsibility" is no longer written in the code, but sinks to the platform to do "service orchestration", that is, the programmer goes to the "service orchestration background" to configure the information (configure each node of the responsibility chain)

A client using "Service Orchestration" in the business system can execute the code according to the process of "Service Orchestration" as long as the ID of "Service Orchestration" is passed in when requesting.

The advantage of this is that the business chain is configured in the background, and there is no need to maintain the chain in the system business, and the flexibility is higher (the written responsibility chain nodes can be combined at will)