The standard descriptions of “business logic” have long left me cold. I want an objective, measurement-based definition for the notion of business logic that I can use to guide the placement and packaging of code as it is being implemented. Ideally, I should make this decision once and that decision is correct.

Definitions such as “business logic .. is the part of the program that encodes the real-world”[Wikipedia] seem circular and imprecise. It feels like an “I know it when I see it” definition. More refined approaches state that business logic handles how “data can be created, stored, and changed”. In practice, presentation layers have several reasons to create and change data that have little business relevance. The creation or mutation of data is not sufficient in itself to define code as business logic.

The standard definitions all rely on the context of a specific business. If you know the business, then you know which parts of the code are business logic. However, if the business process emerges as a consequence of the engineering work, an all too common occurrence, then it is impossible to identify all business logic in advance of its implementation.

The best objective definition of business logic that I know is that behavior which two different presentations need to use to effect a persistent change. Although this definition is objective, it does fail to provide prescriptive guidance. Code that is initially implemented in a presentation layer can emerge as business logic after it is written.

An objective mechanism to determine if code is business logic is essential for edge cases. The notion of “I know it when I see it” is sufficient for simple cases, but it lacks the precision of the “used by two” metric. In emergent software development, the “used by two” metric can require revisiting some software components. Experienced engineers following the guideline “is it likely to be used from multiple presentations” are likely to make good decisions.

• Prev Post