The introduction of rule solutions is a major trend. Compared with tradition, it responds very quickly to frequent changes and multi-style decision-making, which is a more reasonable method. After the introduction, the life cycle of business systems, such as software requirements collection, system analysis and design, coding, testing and maintenance, will undergo profound changes.
Requirements collection
In the case of parallel development, for newly developed systems, business rules are part of the requirements collection. The collection of business rules is collected through different requirements deliverables such as domain models and business use cases. At a deeper level, business rules focus on the business rationale (the business strategy and motivation behind the rules), not the business actions that are driven by the rationale. Accordingly, we need specific processes, roles, skills and deliverables to deal with business rules. At the same time, these processes and techniques for gathering "business rules" or "intermediate deliverables" rely on traditional requirements gathering techniques that companies have been using. If a company has been using use cases to capture functional requirements, then the collection of business rules should be based on contextual information about the decision steps expressed by those use cases. For the case of refactoring the system, the existing system and documents can be used as an important content for requirement collection and also the source of business rules. In this case, the process and techniques of rule discovery are also applicable.
In the case of asynchronous development, we need to clearly separate business rules from processes, roles, techniques and deliverables. Separate from requirements gathering for specific business procedures.
System design
The analysis and design of the system should pay more attention to the business and rely on the rule engine to execute business decisions. In addition, the system infrastructure should be affected as little as possible by specific rule solutions. During the analysis and design of the program, there will be more rules or decision-making aspects. We need to do rule analysis, including decomposing repetitive business logic into several simple automated logics, detecting redundancy, duplication or conflict between rules, and recording the decision-making intent of business rules. It is also necessary to package the rules into a rule set, which consists of integrated components such as testing, deployment, and execution, according to business requirements or program design requirements. We also need to clearly design and list the management components of the business rule management system (vrs), including the structure of the rule base, the rule metadata, the measures to change the process with the rules, and so on. Finally, we need to design the mutual calling interface between the business program and the rule management system.
Code writing for coding
infrastructure, independent of rule solutions. But decision logic will be separated and written through a business rules management system (vrs), we need new processes, techniques, skills, roles and tools to write business rules. The result of this separation is that the two programs can be less coupled and proceed relatively independently. When the infrastructure of the project is completed, we can participate in the project without waiting for the first business rule code class to be written and tested. In this case, the customer would wonder "why have the R&D team been put back into the company while the requirements are still being collected", but we have completed all the business rules before writing a business logic layer code. Some rules have also been tested. In this way, the rule writing problem and the system architecture will be relatively independent.
test
In traditional system development, functional testing is performed when the program has been developed for the most part. Further, black-box functional testing does not provide much help for debugging the business logic of the program, whereas white-box testing requires us to analyze and identify the logic paths in the complex logic operating environment. With the rule solution, we can test relatively independent functions with less architectural code. This is like unit testing of functionality through code execution that can identify, trace, and modify independent logical paths. The testing capability of independent rules is a powerful verification and validation tool.
Maintenance
In traditional system development, maintenance requests all follow a similar implementation path, regardless of business rules or infrastructure code, they are basically like this: the administrator issues a maintenance request, and the request will be sent to the IT staff for implementation. , test and deploy. With the help of rules solution, business rules or decision logic are deployed and maintained independently, we have different business processes to identify business rules and use lightweight rules deployment mechanism. The maintenance of business rules is a part of the whole business management activities. Rules management is deeply influenced by business rules solutions in synchronous or asynchronous development patterns.