Loading
Business logic description – a set of rules, principles, dependencies of the behavior of objects in the subject area.
The problem in the first place is the variability of the system logic. A business application cannot be created forever: changes to the requirements for a business application come in a continuous stream at all stages of its life cycle: development, implementation, operation - because the business process that the application should automate lives and develops. You might think that so many changes are the result of incorrect initial analysis or poor organization of the whole process. But no, this is an objective property of real life, and not only in commercial organizations. For example, in state structures, requirements are determined by regulatory documents (laws, decrees, orders, etc.). It happens that a project for a state structure must be submitted by a certain date, but until the last moment it is not known whether the prime minister will sign or not sign the resolution on which the functional requirements for the system will depend, its exact content is also unknown.
Another specific feature of business applications is the need for data integrity. If the sale is taken into account, it should be reflected in all necessary books of operations. If the sale, reflected in the subsystem responsible for logistics, is not reflected in the balance sheet, this will lead to big problems.
The third specific feature is the inability to predict data access requirements. At the initial stage, it can be impossible to determine required data format for output, its segmentation, and documents. It is necessary to lay such a system so that data output can be changed quickly enough, on the go.
Firstly, by dividing the code into the platform and business logic. This applies to all systems of this class. There is a platform code, that provides basic things, and there is a business logic code, which is used specialized language: for example, Microsoft Dynamics and SAP offer their own languages for writing business logic.
The platform code that solves the most basic tasks is produced by the authors of the platform and changes it only together with the releases of new versions of the platform. The business logic code is constantly changing by the business logic developers.
Secondly, the use of relational DBMS. Despite the strong development of NoSQL databases, relational DBMSs remain the best tool for solving the problems of building business logic. All the main advantages of relational DBMS that are not present in many of the NoSQL databases remain in demand: atomicity of operations - the ability to roll back a transaction with a large number of changes in case of an error, as if it had not started; insulation; ensuring integrity through foreign keys; the ability to quickly retrieve data in an arbitrary format; the need to integrate with a huge number of legacy-systems, the data of which is in relational DBMS.
First of all, we must have standard tools for code control and version control. Today everyone uses Live, then even more convenient “Git ++” will appear. Surprisingly, many “large” platforms for creating business logic online have not resolved this issue: for example, in Microsoft Dynamics, the code is stored directly in the database, there is not even version control.
There should be a convenient IDE, preferably one to which everyone is accustomed and able to work productively: in the Java world, this is IDEA or Eclipse. Manufacturers of "large" platforms, creating their own programming languages, often do not pay enough attention to the convenience of the IDE.
There should be a convenient opportunity for testing code, unit tests should be easily accessible, there should be the ability to carry out test-driven development. Like any other application, business applications should not be wrong.
Business applications must be consistent with the overall IT infrastructure of the project.
