Business: Commercial enterprise: the activity of providing goods and or
services involving financial, commercial and or industrial aspects
Logic: The principles that guide reasoning within a given field or
situation
Business logic code is the code that
applies the principles that guide reasoning within the business. Sounds fancy,
but in fact it is just the code that makes decisions, answers questions, and
applies rules. One might argue that in the common
business application the business logic code is the most
important code. The code you cannot write unless you understand the business
and as such is often defined by experts in the field.
What
is not business logic code?
In short: all the other code. Often
the common business application
also requires code to handle user interaction via graphical user interface
components. There is often code for
database access, code for capturing process algorithms, code for handling
security, code for logging interaction or auditing events, code for managing
errors, code for wrapping external services or components, etc. These subsystems are all required to complete
the application, but are often not directly tied to the business itself.
As mentioned above, business logic is defined by a subject matter expert from
the business the application is being built for, however the developer or other
related technical authority is often the subject matter expert for this other
code.
This
is so clear, could you please add some confusion?
Yes. The subsystems noted above (data
access, user interface code, etc.) also have principles that guide the
reasoning related to them. So although these subsystems are not tied directly
to the business at hand, they do have their own business to attend to and so
the logic involved is also technically business logic. This is important for
the object-oriented developer since the objects created to handle these
subsystems should also be responsible for their own related business which of
course is not the business of the application. This is worth
noting because often object-oriented developers drop their respected OO
principles when working in these other subsystems outside of what they would
consider business logic. I did just that until it dawned on me that I was
missing all the benefits of an OO design outside of business code.
Why
is it important to identify business logic?
- Business changes frequently and we have to know where to look, what to change, and how to easily test our changes
- When discussing the logic with subject matter experts after it has been implemented, we need that logic isolated and at the right level of abstraction without peripheral distractions to minimize logic-to-code translation
- So the business logic code can be kept separate from other code to make sure changing either has little to no effect on the other. Rude developers have a habit of spreading business logic all over an application from the user interface through stored procedures
- We have to be sure not to duplicate business logic so when it needs to change (as it is highly prone to do) we make sure the logic is changed and fixed for all code dependent on that logic
- Business logic is often tied back to requirements to make sure features are implemented correctly
What I might point
out is that it might still be wise of us to track the difference between these
two types of business logic. For what is often the case is that one tends to be
an add-on to the other.
Imagine a system that manages insurance details for customers. The business
logic relating to the business of insurance may exists along with business
logic that deals with the business of security along with some auditing
requirements. Understanding these separate needs, these separate businesses is
necessary in order to keep concerns separated and allow for objects that have
just one reason to
change (SRP: Single Responsibility Principle) of SOLID design
principles . In an ideal design the object that has business
logic related to insurance would not also contain logic that has to do with
security and or auditing. We should be able to make changes to our security
model (or swap it out entirely) without breaking our business code.
No comments:
Post a Comment