Multilayered architecture (1) – Introduction

Introduction

If you ever worked in an IT project, you would probably know how necessary it is to factorize the source code to avoid that the entropy will take possession of your project as soon as it becomes larger and larger… If you ever encountered one of those scenarios:

1. I started with a small project where everything was working fine but by the time it evolved so much that it was not easy anymore to properly find my logic in the code!
2. I have a huge system to design, I need to think at a scalable, flexible, extensible and evolvable architecture!

Well, probably an Multi Layered Architecture (MLA) is what you need. MLA is an architectural model that propose the organization of the software components into different layers. Each of those layers is implemented as a physically separated container of software components.

The main design principle behind an MLA is the Separation of Concerns (SoC). Concerns can be conceived depending on the type of project with the only restriction that the boundaries among different concerns must be clear and well defined.

In this post we will introduce the most common SoC that can be applied to create an MLA. Personally I experienced this model in the refactoring of a huge project that started with a modular architecture and then needed to be refactored once Quality & Safety norms had to be applied to the project development process requesting a higher level of testability (unit test, integration test, non regression test, functional test), traceability (reqs to source code & reqs to software design components), and code quality (we are speaking about SIL…).

What we need to design an MLA

To build an MLA you don’t need a specific technology or vendor platform but it is preferable to use a technology that permits to realize loosely coupled components as:

• Service Contract/Implementation physical separation (as SOA, WSDL for web services and the HTTP for Rest Services)
• Dependency Injection
• Dependency Lookup

Layers are composed of loosely coupled components, but each layer can be seen as a component and so design principles can be applied to it; for example, we can realize Architecture Composability using this principle. This will be better described in the Infrastructure Layer part.

In my case the application was built using the NetBeans Rich Client Platform that supports loose coupling via the Lookup API, an extension of the Java 6 ServiceLoader.

The 4 Layers

The whole system can be divided into 4 main layers:

• Domain
• Application
• Infrastructure
• Presentation

Having a look at the following dependency diagram we can fix some main concepts:

• The Domain Layer is the root of the architecture, it contains all the entities that are built from the business domain derived from the project scope.
• The Application Layer uses all domain entities and logic to build basic application logic, that can be assembled and composed to create larger processes.
• The Infrastructure Layer defines the link with the technologies used, for example database persistence, file system, legacy systems, XML persistence, etc etc. The main importance of this layer is that it provides implementation of services defined in both Domain and Application Layers. As you can see in the dependency diagram it can be easily changed with another implementation as it is simple a service provider component.
• The Presentation Layer contains all the User Interface, and process definitions. It could be a Java Swing Layer with Actions used as process entry points composing different application logic in single transaction, or can be a web oriented User Interface Layer integrated into a web application. Also this layer can be changed, as the infrastructure one.

Enterprise considerations

By the point of view of an enterprise, having an MLA can be very interesting because it would naturally support the IT Resources Reusability and so the Agility of the whole enterprise. Thinking at this architectural model, we can imagine that the Domain Layer could create a Federated IT Resource that could be easily shared between the different projects of the enterprise; this is why, when designing the Domain Layer, Autonomy is an important design principle to take into consideration.

Application Layer still has a chance to be reused, but in most of the cases it is linked to specific requirements and so to processes that are not intrinsically designed to be reusable.

Finally Infrastructure and Presentation Layer exists just to support one project, so instead of Reusability other principles are more important like for example Scalability, Performance and Simplicity.

Building an MLA

When an MLA is put in place the build strategy can be very simple. You have to consider that each layer is a physically separated source of code, hence it easily permits to create builds of the application taking only the necessary layers and from each layer only the necessary modules for the application to be built. If then the used platform support the Modular Architectural pattern, as NetBeans Platform or Eclipse Platform, the task is even easier. It is possible to build applications with different infrastructure providers, using just a subset of the features or with experimental modules from an under development new layer.

Testing an MLA

Once Loose Coupling has been fully applied to our MLA Testability will gain power. You will see how easy is to create tests in automated testing environment as JUnit independently for each layer. Using a Continuous Integration Tool like Jenkins and a Quality Tool like Sonar, we can easily have quality metrics on the source code for each layer, giving the chance to easily individuate potential problem or required improvements in the code.

Finally separation of layers permits to easily map functional requirements with system modules, helping in the evaluation of the impact of changes in order to establish which tests will need to be passed again before a release.

Conclusions

Naturally the proposed model is not the only possible one, neither the best one. The design of an MLA can vary and depends on the scope, needs, technologies and field of application of the project. What we just discussed so far is a real case experience for the application of several design principles that allow to create an MLA to manage high Quality and Safety norm specifications for the Development Process of the project.

By the way this is the most common model and I believe it can perfectly fit to standalone or distributed applications and has a great parallelism with an SOA design (thinking of the categories Entity, Utility, Application and Process services).
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

I agree to the Terms and Privacy Policy

Sign up

Thank you!

We will contact you soon.