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 (4) – The Infrastructure Layer

Introduction

What is Infrastructure? If we think at a building, Infrastructure is what brings light and water. You can build a wonderful house, but if you don’t connect it to the city infrastructures, you will never be able to live in it. Finally this building is able to receive water and light, but is not linked to any specific water or light distributor. I can start a contract with energy company A and change to energy company B if needed.

If we come back to software engineering, Software Infrastructure is what gives energy to our system: a database technology, a network protocol, or a file system implementation. It is part of software architecture, but as for a building the vendor-neutral principle should be adopted, that means decouple the software architecture from any specific infrastructure implementation, to be able to switch easily from a technology to another.

Persistence layer

One of the most important part of the Infrastructure Layer is the Persistence Layer. Persistent is whatever an object that is able to live independently of a software. Typically a database is a persistence representation of a certain set of data. As discussed in Domain Layer domain objects usually need to be persisted. But persistence is not directly part of business documents! You never speak about database table with business expert, but you speak about objects. So it is very important to keep the two concerns separated:

  1. The definition of business objects is part of the domain layer
  2. The mapping of business objects into a persistence model is part of the Persistence Layer (infrastructure layer)

A possible implementation

In my experience I learnt a way of implementing a Persistence Layer. As basic idea business objects are exposed only via interface. Pure implementation of those business objects are not exposed, and available simply using Factories, also exposed via interface and gathered via Lookup or ServiceLoader. Finally to define the persistence layer with an ORM as Hibernate or EclipseLink, XML mapping is the preferred choice.

I know most of you will complain about the use of XML instead of Annotations, but annotations are too much intrusive for the scope that has been prefixed to separate business objects from their persistence infrastructure technology. Annotations put persistence metadata into the domain object, but what if those objects need to be reused by another application that want to persist them in a complete different way? The principle of separating the two concerns foster Reusability of the domain layer.

Multiple infrastructures

Hibernate could be just one of the possible persistent representation we want to give to our business objects; what if also we also want to be able to marshall them into XML? For this reason we could think to implement several infrastructure implementations, and make all of them available to be chosen dynamically at run-time, or statically at integration-time. The scope is that whatever implementation we use, the system has to continue to work in the exact way. It simply receives a source of data, if this source is an XML repository, a database or a file system, by the point of view of the application, nothing must change.

So a perfect implementation of a Multilayerd Architecture is one where a changement on the infrastructure will not have any impact on the other layers.

Conclusions

The Infrastructure Layer is what gives energy to a system, that means you will not be able to run a software without it. So even if designed as the last phase, it is implemented quite soon. It is also possible to implement some fake infrastructure technologies and postpone the final implementation, when domain layer will be fully implemented; this will avoid the risk to continuously change the infrastructure implementation every time business objects need to change.
 

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 two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


+ two = 6



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
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.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

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

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close