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

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.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

4 Responses to "Multilayered architecture (1) – Introduction"

  1. Tony Marston says:

    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 sum of all its separate components.

    I liked this idea so much that when I switched to PHP for its superior web development capabilities I constructed my own framework based on the 3 Tier Architecture. This framework will generate the Business layer components using the database schema, and it will generate user transactions from a selection of transaction patterns.

    In my opinion the 3 Tier Architecture is superior to your MLA. Unless you have an MLA framework which can generate components for you, thus saving developer effort, then your MLA is just another idea which takes a lot of effort to implement.

    References:

    http://www.tonymarston.net/php-mysql/3-tier-architecture.html
    http://www.tonymarston.net/php-mysql/infrastructure.html

    • Marco Di Stefano says:

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

      You say that 3-tiers is superior to Multilayered architecture, but as far as I learnt there is no superior solution in IT, at least that you specify a particular context or scope of the architecture. As I understand you speak of PHP web application so in that case, probably 3 layers are enough.

      Finally your sentence “then your MLA is just another idea which takes a lot of effort to implement” is not exact, first because MLA is not my idea; scope of the topic is to discuss about a real experience on the implementation of a confirmed architectural model that has given undoubted results. Second because no efforts are needed, all you need is a framework that allows separation of contract/implementation as Java or other common languages provide.

      The concept of 4 layers comes from domains like SOA, Enterprise Architecture and Enterprise Automation Tools. For example in the TOGAF methodology it is defined 4 categories of architectures Business, Data, Application and Technology and in SOA is common to use entity, utility, task and business process layers; both are in a way linked to the 4 discussed layers.
      When you speak of a framework that generates the business layer from the database you are really far from the scope of the MLA I am proposing, since in an MLA Database schema will never exist prior to the domain layer, as the domain layer is built studying the business documents to identify a federated and reusable resource in the enterprise, and the database is just one of its possible persistence representations (others could be XML, in memory data model…).

      So, probably your solution fits very well with the scope defined for your architecture, but to create Enterprise Architectures and foster reusability, intrinsic interoperability, federation and agility maybe the approach I propose can be a better solution.

      • Tony Marston says:

        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 two so that the separate parts can exist in the Business and Data Access layers.

        I have been developing database applications for over 30 years using a variety of languages, database engines, methodologies and frameworks, and if a methodology/framework requires a great deal of effort to implement then you are increasing the opportunities for a poor implementation. Once you have chosen a particular multi-layer or multi-tier architecture it should be possible to create a framework which actively supports that architecture and helps you generate application components that fit within that architecture. I developed my own framework for building web applications in PHP over 10 years ago, and I have yet to see anything in any language to match it for speed of development and facilities available.

        Does the MLA which you describe have a supporting framework?

        • Marco Di Stefano says:

          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 in SIL0-4 environments or within safety norms, you are obliged to follow strong and not agile methodologies to be able to have your tools accepted and used in operational environments.

          About a supporting framework, in my experience with Java projects all I needed was a good IDE as NetBeans or Eclipse. When applying to SOA a framework is not needed as SOA Architecture methodologies exist defining all the necessary steps and requirement. Applied to Desktop Automation Tools I have been using the NetBeans Rich Client Platform, but even this is not necessary cause with Ant builds you can achieve the same results. In SOA one of the main characteristic is being vendor-neutral that means that you do not have to link to any vendor or own framework implementation to decouple the evolution of your solution from technology aspects. This is why I cannot discuss about any specific framework, to keep the vendor-neutral characteristic.

          Anyway, if you speak about database applications (and also in other contexts), I am agree that your framework fits very well. For an enterprise architecture, probably will not be the most suitable solution.

Leave a Reply


× nine = 63



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.