Editing Business logic (section)

==Business logic and tiers/layers==
{{More citations needed section|date=January 2018}}
[[Image:Overview of a three-tier application vectorVersion.svg|thumb|right|Business logic in theory occupies the middle tier of a 3-tier architecture]]

Business logic could be anywhere in a program.  For example, given a certain format for an address, a database table could be created which has columns that correspond exactly to the fields specified in the business logic, and type checks added to make sure that no invalid data is added.

Business logic often changes.  For example, the set of allowable address formats might change when an online retailer starts shipping products to a new country.  Thus it is often seen as desirable to make the code that implements the business logic relatively isolated, or [[coupling (computer science)|loosely coupled]].  This makes it more likely that changes to business logic will require a small set of code changes, in only one part of the code.  Distant but strongly coupled code also creates more of a risk that the programmer will only make some of the necessary changes and miss part of the system, leading to incorrect operation.<ref>{{cite book|url=https://archive.org/details/isbn_9780201738292|chapter=Introduction to Enterprise Software|author1=Khawar Zaman Ahmed|author2=Cary E. Umrysh|name-list-style=amp|publisher=Addison-Wesley|date=2001-10-17|isbn=0-201-73829-5|title=Developing Enterprise Java Applications with J2EE and UML}}</ref>

A [[multitier architecture]] formalizes this decoupling by creating a '''business logic layer''' which is separate from other tiers or layers, such as the [[data access layer]] or [[service layer]].  Each layer "knows" only a minimal amount about the code in the other layers—just enough to accomplish necessary tasks. For example, in a [[model–view–controller]] paradigm, the controller and view layers might be made as small as possible, with all the business logic concentrated in the model.  In the e-commerce example, the controller determines the sequence of web pages in the checkout sequence, and is also responsible for validating that email, address, and payment information satisfy the business rules (rather than leaving any of that up to the database itself or lower-level database access code).

Alternative paradigms are possible.  For example, with relatively simple business entities, a generic view and controller could access database objects which themselves contain all the relevant business logic about what formats they accept and what changes are possible (known as the [[database model]]).

Some tiered schemes use either a distinct [[application layer]] or a [[service layer]], or consider the business logic layer to be the same as one of those.