Business logic
In
computing, in particular in
object-oriented analysis and design of business computer systems, the
business logic of a software system (sometimes called the
domain logic because it relates to the problem domain
or the
functional process logic) is that part of the whole system that deals with the performance of business-related tasks, such as transactions or
account updates. It is distinguished from
presentation logic, which is the part of the system that embodies the presentation of the objects in the system to the user, and from the
CRUD layer, which is the part of the system that embodies the raw database access.
Business logic
* models
real life business objects (such as accounts, loans, itineraries, and inventories);
* handles the storage of business objects (e.g. the mappings from the business objects to the database tables in the CRUD layer);
* prescribes how business objects interact with one another; and
* enforces the routes and the methods by which business objects are accessed and updated.
Business logic comprises
:
*
business rules that express business policy (such as channels, location, logistics, prices, and products); and
*
workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.
|
Business logic in theory occupies the middle tier of a 3-tier architecture. |
In single-tier applications, business logic, presentation logic, and CRUD are often fused, with each having intimate knowledge of, or being strongly
coupled to, the others. This is seen as problematic, since changes to one result in changes to both of the others, requiring retesting and revalidation of the entire system for a single change. The interweaving also limits the extent to which the CRUD and the business logic can be
reused.
In a
multitier architecture, business logic is a separate module. In the common
3-tier architecture, the business logic in theory occupies the middle tier, the business-services tier or
business layer. In practice, the business logic is often interwoven in the other two tiers (the user services tier and the database services tier), such as by encoding business logic in
stored procedures and in decisions about input validation and display formatting. Hower
and others strongly argue against this practice, and advocate storing
all business logic in a business layer, and not encoding any business logic an application's user services or database services tiers.
Business logic can be extracted from procedural code using a business rule management system.
* — McLaughlin discusses the
façade pattern for implementing the business layer of an application.
*
* — Turau presents an application framework implemented using
Java Servlets and
Java Server Pages that enables the separation between business logic and presentation logic, allowing development of each to proceed in parallel along relatively independent but cooperating tracks.
* — Pau and Vervest develop an approach for the embedding of business logic into the communications network that underlies a distributed application with a multiplicity of
actors, in order to optimize the allocation of business resources from a network point of view.
*
Enterprise JavaBean*
User interface management systems*
Magic pushbutton
