What do we actually mean when we say “business logic”?

“Business logic” is supposed to refer to a specific part of a system, i.e. the code where we create real-world business rules around how data is created and changed.

In reality it often refers to the poorly-defined “gloop” that sits between user interfaces and databases in layered architectures. The presentation logic manages the interaction with the user, the data logic handles data persistence while business logic handles the “stuff” that happens between the two.

It can be difficult to precisely define what this “stuff” really means. The business logic layer can become a generic bucket for processing that does not fit into the presentation and data tiers. Anything that involves some kind of transformation or workflow just gets dropped into the tier by default.

Business logic vs business rules

Business logic is often mistaken for something that encapsulates the businessrules implemented in a system. There is an important difference between the two. Business rules are a formal expression of business policy, while business logic determines how this policy is implemented as a process. For example, the application of VAT on invoices is a business rule but the calculations involved in applying it are implemented as business logic.

The catch is that the separation between business logic and other parts of the system is not necessarily that clear. Many business rules need to be implemented across more than one tier. For example, a business rule that dictates that negative figures should always be presented on financial reports affects both data processing and report writing, i.e. presentation and business logic.

This is one of the drawbacks of tiered or layered architectures that seek to isolate business logic into a separate tier. It can be difficult to meaningfully segregate functionality into a self-contained tier depending on the type of processing that is being carried out.

Over the long term this “business logic” often leaks across tier boundaries so the implementation of business rules becomes scattered across a system. This gives rise to anti-patterns such as “shotgun surgery” where any change in a business rile requires numerous changes in different parts of the system.

The dangers of conceptual architecture

Separating a system into conceptual layers or tiers can give rise to inflexible solutions. Many layered architectures solve every single problem in exactly the same way, i.e. you accept user input on a presentation layer, apply some rules in a “business logic” layer and persist it via a data later. Rinse and repeat.

The problem with this kind of generic solution is that it is a mistake to imagine that system architecture can be abstracted from infrastructure. You can’t consider the conceptual design of a system without also considering how it will be deployed and the strategies around scaling and resilience.

This is where layered applications often come unstuck. The interfaces between each layer tend to be relatively chatty and pass data around in small chunks so they can struggle to distribute processing. System tends to be inefficient as much of the work being done involves transferring data between layers rather than implementing business rules. The use of single, generic processing routes encourages systems to be orientated around a centralised database that can become a bottleneck at scale.

Towards more specialised implementations. Or services.

The processing that happens in “business logic” is an important part of systems, but putting it into a single conceptual tier may result in generic solutions that can’t scale and are difficult to change. Once you start trying to unpack business logic it’s often easy to identify concerns that would benefit from more specific implementations.

This is where services come into the picture. Instead of organising systems according to type of processing we organise them according to data and behaviour. If a single processing unit can encapsulate a cluster of related functionality then any implementation is more likely to be able to change in response to real world needs.

The notion of “business logic” does not have any relevance in this context. Systems become aligned to real-world concerns rather than the conceptual definitions of software architects. They are defined by the data and behaviour that they implement rather than the type of processing they carry out. The end result is something far more responsive and scalable than a monolithic set of layers.

About me

I am a London-based technical architect who has spent more than twenty years leading development across start-ups, digital agencies, software houses and corporates.
Over the years I have built a lot of stuff including web sites and services, multi-screen applications, systems integrations and middleware.

My current focus is on enabling scalable SaaS delivery and providing architectural leadership in agile environments.
I currently work as Chief Architect for Wolters Kluwer UK leading them to cloud heaven, one service at a time. Opinions are my own and not the views of my employer, etc.

Recent

There does seem to be growing confusion over what Service Fabric is really for. Is it an orchestrator for microservices? A means of lifting and shifting legacy applications into the cloud? An application development framework?

Azure Functions only provides direct support for a narrow range of authentication providers. If you want to use an external token provider or custom solution, you’ll have to create the plumbing yourself.

ArchUnit is a java library that provides a fluent API for creating self-testing architectures via unit tests. A similar library can be written for .Net Standard that acts on compiled assemblies rather than raw code.

There is a growing sense of unease around how larger organisations have implemented agile. In particular, there is a tendency towards centralised control that can be at odds with the agile preference for individuals over process.