|
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.••
Scope of business logic Business logic Business logic comprises•: Location of business logic 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 in the application's user services or database services tiers. Tools for handling business logic Business logic can be extracted from procedural code using a business rule management system.• Further reading See also | ||||||||
|
| |||||||||
 |
|
| |