Software Development

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).
 

Reference: Multilayered architecture (1) – Introduction from our JCG partner Marco Di Stefano at the Refactoring Ideas blog.

Marco Di Stefano

Marco is a software engineer specialized in software architecture and process automation. He has been involved in all the software v-cycle phases and actually he works for the railway industry.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Tony Marston
Tony Marston
10 years ago

I first came across the Multi-Layered Architecture in 1999 in a compiled language called UNIFACE where it was known as the 3 Tier Architecture. It has a Presentation layer, a Business layer and a Data Access layer. It came with a selection of pre-built components for the Data Access layer so you could change from one DBMS to another without changing any code in any of the other layers. You had to use its IDE to build your own components in the Presentation and Business layers. It had no concept of an Application layer as an application is surely the… Read more »

Marco Di Stefano
10 years ago
Reply to  Tony Marston

Hello Tony, thanks for your comment and the interesting links. I would like to discuss about some of your points. First of all the meaning of layers and tiers in my post. As several architecture patterns define: “a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure”. Indeed for me a multilayered architecture with 4 layers can still be a 3-tier architecture as far as it will be deployed in 3 different infrastructures. I think that in your discussion layer/tier are used… Read more »

Tony Marston
Tony Marston
10 years ago

While some people may think that ‘layers’ and ‘tiers’ are different things – one is logical while the other is structural – I am not so pedantic. A chocolate layer cake has ‘layers’ while a wedding cake has ‘tiers’. Even the Wikipedia definition at http://en.wikipedia.org/wiki/Tier says that the two words are interchangeable. I agree that it is possible to have more than one component in each tier/layer. My own framework uses a combination of the 3 Tier Architecture and the Model-View-Controller design pattern where the View and Controller exist in the Presentation layer and the Model has been split into… Read more »

Marco Di Stefano
10 years ago
Reply to  Tony Marston

Hi Tony, is not being pedantic, simply to define an architecture you need two concepts one that is the logical representation and another that is the physical deployment; for this reason layer and tier are considered separated, to provide the right terms to define things. But anyway is just naming convention, we just have to agree on a terminology mapping to be able to discuss. What you call component I call it layer, and what you call layer/tier I call it tier. About the complexity added, it is true that methodologies complicate things, but in certain domains, as when working… Read more »

Back to top button