Wednesday, February 03, 2010

Where is business logic?

Have you ever heard of Multitier architecture? If not, you have probably encountered it without knowing its name while working on web applications.
In a multitier architecture, an application is divided in different horizontal layers, each addressing a different concern. Every layer builds on the one that lies directly under it to perform its work, thus decoupling for example html presentation (upper layer) from sql queries (lower layer).
The number of layers is flexible and there is a high number of variants for a multitier architecture, but the simplest model many web applications fall in is composed of three layers:
  • user interface: generates html, handles user input and displays errors.
  • Domain Model: objects and classes that represent concepts, such as Post, Thread, Forum, User, Message and so on.
  • Infrastructure: usually data access code to a database and, by extension, the Sql schema itself where the relational model is used. External services also qualify as infrastructure.
Thus there are three major approaches to development, which differ in the layer of the application that contains the greater quantity of business logic. Which User can close a particular Thread and in what order the Messages for a particular User are listed? In which Forum a User can add a Post?
The answers to these questions ideally reside in one of the fundamental layers as specifications require (though sometimes they are scattered trough the layers, which is a very effective way to complicate a design.)

Smart Ui
As the name says, this style keeps the logic in the user interface. A Smart Ui example is a folder full of php scripts that move data back and forth from a MySql database.
During maintenance, usually the replication of rules and code in different scripts increase, rendering difficult to change and expand the application; this style is appropriate only for small projects which only shuffle data from tables to html pages.

Smart database
A style primarily taught in database classes, which result in a very accurate schema, full of constraints, triggers and stored procedures to maintain data integrity.
Note that if you want to implement this approach, you probably need an expensive database like Oracle because open source databases do not support all the logic you need. Moreover, Sql is not a programming language, you can stretch Ddl with proprietary extensions and set up many rules but you will be replicating them in the front-end (if there is one at least) for error handling and localization.

Rich Domain Model
The most powerful approach is implementing logic in the domain model layer, which is the type of model that should be able to best represent the real world.
It follows that in such an approach the Ui delegates nearly everything to the domain layer, or it is even automatically generated (Naked Objects). Technology is available for the database to be generated automatically once a mapping from objects to tables is defined (Orms like Hibernate and Doctrine 2). The dependencies are inverted as all other layers mirror the domain model.
The advantages of a rich domain model are multiple:
  • testing is simple because infrastructure and Ui do not get in the way; no need to run databases to test business logic or to fill forms with a bot or Selenium.
  • no duplication of logic is permitted, because different views of the user interface refer to the same methods in the domain model.
  • the model of the application is the model presented to the user; there is no translation between concepts and no need for him to learn a data model along with a presentational one. Often a Presentation Model is needed because the underlying Domain Model is anemic.
Essentially with the tools available today for managing generic layers you can achieve everything by manipulating objects directly in memory and storing the result in the database by pushing a big Save button.


alberto said...

Presentation Model and Anemic Domain Model have nothing in common, they are orthogonal concepts.

It is precisely when you have a rich and complex domain model that PM comes in handy.

akond said...

The link to the picture is incorrect.

Giorgio said...

Thanks for noticing, it was a typo.
About the Presentation Model: in my mind (and in Evans's DDD book) the model presented to the user should not undergo a transformation from the domain model form. Of course there are different styles of programming. :)

Ruslanas said...

Almost all projects I've seen so far that were implemented using "rich domain" approach have suffered from performance problems.
Of course, if all you have is MySQL, you have no chance to put your logic into database, so "rich domain" is the only way you can go; however, if you use database empowered by normal programming language (I mean Oracle PL/SQL, that hails from Ada), putting logic into the DB gives you a lot of advantages:
1. Usually, business logic requires lot of data manipulation, so you can do it more efficiently into the DB without additional traffic/connections between middle tier and DB; you call DB "service", passing only required parameters and getting only final answer, without mediation data.
2. Programmer that specializes in the database will write MUCH effective code than, let say, Java programmer, and DB programmer will code much faster.
3. Refactoring of DB schema is much easier when you expose only "interfaces" to your DB operations, not schema objects.

//Moreover, Sql is not a programming language//

Of course, Sql is not. PL/SQL, TransactSQL are.

// no need to run databases to test business logic or to fill forms with a bot or Selenium.//

You will be surprised after your data will grow, and that surprise will not be exciting for you, believe me.

//set up many rules but you will be replicating them in the front-end (if there is one at least) for error handling and localization.//

Actually, I don't understand why duplicating is needed at all? DB "services" just raises exceptions, and your front-end/middle-tier should be able to deal with that exceptions - present them to users in correct way, that depends on technology you use.

Giorgio said...

The choice is between an object model and a relational model: a relational model in a costly database like Oracle can certainly encapsulate the same logic of a domain model, but there are some advantages of an object model, mostly that it can best represent the reality (relational model does not support *natively* 1:N associations between entities) and that its test suite can be run by a developer on his Celeron laptop on Saturday morning in his bed. :) Again, everyone of us has different preferences about what to use to get things done.