Every software has some business logic. It is easy to talk about business logic but hard to define what exactly it is. Presentation is easy to explain, that is that’s where you view is. And the database is easy, that’s where your data persistence is. It is this middle thing that is a little hard to define. And it is the topic of my latest lecture in by Design and implementation of software course, Organising Domain Logic.
In the lecture I look at ways in which we can organize the this middle layer, where this “business logic” is. The trick question is this: how do you define “business logic”? In fact, the very term does not sound right since business is anything but logical. Having worked in business for many years, logic is not what comes to mind. A clever software programmer might be able to figure everything out, only to get a feature request that completely violates everything about the design.
Since business logic is misleading we will use the term domain logic. A domain is the area of expertice you are working in. If you application is a real estatate property web site, your domain is houses, number of rooms, type of houses, attributes such as gargae, one door or two, swimming pool in the garden and so on. Then there is logic such as viewing property, asking for information, contacting the real estate agent, requesting a visit and so on. If you domain is cars, it’s all about engines, milage, number of doors, and many interesting things about cars.
One way to organize systems in general is to use layering. This is the oldest trick in the book, divide and conquer. With layering each layer has a precise and well defined role. You can ignore everything else, just focus on the logic in the layer. There are three principal layers in any software systems: presentation layer, domain layer and data source layer. You can have more, depending on the system but these three that are universally used, even if the lines are blurry.
I present three design patterns from the textbook (Patterns of Enterprise Applications) that help us organise the domain layer. First, and the simplest is to view your domain as a set of procedures that handle each business transaction is the system. This pattern is know as Transaction Script. You create a script for each request of the presentation that will take care of the transaction performed. The second one is Domain Model. In this the focus is on building a set of classes that represents your domain. Here the focus is on designing a object representation that solves the domain problem. This way is much more flexible that scripts, but introduces some complexities. This works well if the problem begin solves is difficult and building an object graph is need. To give access to the domain model, a Service Layer, may be applied. The third is Table Module, where a class is representing a table or set of tables in the database. Each class will have all the domain logic relating to the data. This works well if the domain problems are centred on the data and support for manipulating the data is good.
In the lecture we also create simplistic Domain Model example, and build a movie database. But of course.
Lecture: Organising Domain Logic