Business Logic Development Pitfalls
Even though software development is an established business, I must state the fact that Business Logic is still a myth in the world of information technology. A good example of such a myth or, I would say, a common misconception are the definitions of business logic on the Wikipedia website ( https://en.wikipedia.org/wiki/Business_logic ):
· Business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed.
· Business logic prescribes how business objects interact with one another.
· Business logic enforces the routes and the methods by which business objects are accessed and updated.
· Business logic Is the portion of an enterprise system which determines how data is transformed or calculated .
To put it mildly, none of the above statements define business logic. We had already given the right definition of the business logic in the chapter “Business Logic” by saying that “ Business Logic is the process of selecting the target state of a business process according to business rules, performed after completing the analysis of the data collected in the current state of the business process ”. What then do the statements on the Wikipedia website say? Let's look at them in order.
The first statement on the Wikipedia website defines the data accessing logic:
· Business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed.
Here is our definition of data access logic, which was given in the chapter "Data Access Logic": “ Data Access Logic is the process of managing CRUD (create, read, update, and delete) operations according to business rules in a specific type of data store. ”
The second statement from Wikipedia has nothing to do with business logic:
· Business logic prescribes how business objects interact with one another.
Business objects interact with each other using a set of their properties, methods, and events defined in the classes from which they were created. Business objects do not only interact with each other in business logic. They can interact anywhere - in presentation (state) logic, in business logic, in data processing logic, or in data access logic.
The third statement on the Wikipedia website is rather cryptic:
· Business logic enforces the routes and the methods by which business objects are accessed and updated.
The most likely assumption is that the author had some API in mind when formulating it.
The fourth statement of the Wikipedia site defines data processing logic:
· Business logic Is the portion of an enterprise system which determines how data is transformed or calculated .
Here is our definition of data processing logic, which was given in the chapter "Data Processing Logic": “ Data Processing Logic is the process of managing overall data processing according to business rules as a business process transitions from state to state. ”
The lack of a clear definition of business logic leads us to software products in which the business logic layer exists but does not contain any code. I have seen many similar cases in the past and it looks like this trend will continue in the future.
Table of Content Software Development Pitfalls Previous: Presentation Logic Development Pitfalls Next: Demystifying Unit Testing in Business Domains