Layering application classes is common to separate complicated software. Some even say it is imperative for enterprise applications [Brown et al]. The principal benefits are increasing reusabillity, extensibility, testability and ease of understanding through decoupling, separation of concerns and adopting standards. The problem is almost always on how to layer your application: which layers to use? what will be their responsability?
There are several models of layering architectures. Some define complex layering, like the Brown model, described in "Enterprise Java Programming with IBM WebSphere" [Brown et al]. Others incorporate architectural decisions on technology, like Nilsson model, described in ".NET Enterprise Design with Visual Basic .NET and SQL Server 2000" [Nilson], that has 2 layers of Stored Procedures. A good abstraction that I've read about lately is Martin Fowler's model. It is based on the Brown model but with a more general view, with only 3 layers, and more flexibility for applications that decide, for example, not to use a rich Domain Model or a Service Layer.
Next we'll see about the Brown (Part 1), Marinescu (Part 2) and Fowler (Part 3) models.
The Brown Model
In [Brown et al] it's stated a common 3-layered architecture composed of Presentation, Domain and Data Source. Both the Brown and Fowler models start from this architecture.
The Brown model separates functionality from Presentation and Data Source into two new layers: Controller/Mediator and Data Mapper. In short, the layers can be defined as:
- Presentation: elements to display information to the user and capture input;
- Controller/Mediator: creates an increased separation of the presentation elements and the domain model. These objects maps use cases or application functionality without coupling with the persistence objects. Every request from the presentation must pass through this layer that uses the domain model to generate results. The mediator must be capable of being used by several presentation layers;
- Domain Model: objects modeled after business elements and rules. Main part of a system. Should be as decoupled as possible from technologies and other layers;
- Data Mapping: abstracts functionality to access and persist data in a data source, so it is not mixed with the domain model;
- Data Source: classes and resources to store data. Commonly SQL and a driver of a relational database, but can be a message queue system with an specific API, files, etc.
This model maps nicely with the Java EE 7 platform application model. A possible architecture is:
- Presentation: JSF Facelets (xhtml) and auxiliary CDI classes to extend presentation functionality like messaging and file upload;
- Controller/Mediator: CDI or EJB classes with no reference to JSF components (using only Data Binding) that can be use as an interface to other presentations;
- Domain Model: POJOs representing business elements and rules. Must have methods for obtaining themselves as well, which in turn use the Data Mapping Layer;
- Data Mapping: JPA2 library, used in Domain Model objects;
- Data Source: a relational database like PostgreSQL without any domain functionality (like stored procedures);
It's easy to make mistakes when using this model, like adding FacesContext or JSF component objects to Mediators or accessing the Data Mapping layer from Domain Model when it has a Service Layer. But it is a very robust model that can be used in high complexity applications.
Also, this model can't be used in some RAD environemnts. For example: the ADO.NET TypedDataSets and integrated GUI components introduced in .NET 2.0 forces the application not to have a Domain Model. We'll see more about it in Part 3, in Fowler Model.
[Brown et al] Brown et al. "Enterprise Java Programming with IBM WebSphere". Addison-Wesley, 2001.
[Nilson] Nilson. ".NET Enterprise Design with Visual Basic .NET and SQL Server 2000". Sams, 2002.