Business logic

From Wikipedia, the free encyclopedia

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[1] 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.[2][3]

Contents

[edit] Scope of business logic

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[4]:

  • 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.

[edit] Location of business logic

Business logic in theory occupies the middle tier of a 3-tier architecture.
Enlarge
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.[5]

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[6] 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.

[edit] Tools for handling business logic

Business logic can be extracted from procedural code using a business rule management system.[7]

[edit] References

  1. ^ Simon Brown (April 2003). Implementing Business Logic in J2EE Applications.
  2. ^ Paragon Corporation (2003-07-19). Separation of Business Logic from Presentation Logic in Web Applications.
  3. ^ "business logic". TechEncyclopedia. (2006). CMP Media.
  4. ^ Steven Minsky (2005-03-27). The Challenge of BPM Adoption. eBizQ.
  5. ^ Khawar Zaman Ahmed and Cary E. Umrysh (2001-10-17). “Introduction to Enterprise Software”, Developing Enterprise Java Applications with J2EE™ and UML. Addison-Wesley. ISBN 0-201-73829-5.
  6. ^ Chad Z. Hower. Dude, where's my business logic?. The Code Project.
  7. ^ James Owen. "Bring business logic to light: JRules 4.5 tames business rules with friendly tools", JavaWorld, 2003-09-19.

[edit] Further reading

[edit] See also

In other languages