Understanding Spring Web Application Architecture:the Classic way--Reprint

Original address: http://www.petrikainulainen.net/software-development/design/ understanding-spring-web-application-architecture-the-classic-way/

Every developer must understand, things:

1. Architecture design is necessary.
2. Fancy architecture diagrams don ' t describe the real architecture of an application.

The real architecture is found from the code that's written by developers, and if we don ' t design the architecture of our Application, we'll end up with a application that have more than one architecture.

Does this mean, developers should be ruled by architects?

No. Architecture design is far too important-be-to-be-the-architects, and that's why every developer, who wants To is more than just a type writer, must is good at it.

Let's start us journey by taking a look at the and the principles that would help we to design a better and a simpler Architec Ture for our Spring powered Web application.

The pillars of a good Architecture

Architecture design can feel like a overwhelming task. The reason for this was that many developers was taught to believe that architecture design must being done by people Guardians of a mystical wisdom. These people is called software architects.

However, the task itself isn ' t so complicated than it sounds:

Software architecture is the "high" structure of a software system, the discipline of creating such a high level struc Ture, and the documentation of this structure.

Although it is true this experience helps us to create better architectures, the basic tools of a architecture design are actually quite simple. All we had to follow these and principles:

1. The separation of concerns (SoC) Principle

The separation of concerns (SoC) principle is specified as follows:

Separation of concerns (SoC) is a design principle for separating a computer program to distinct sections, such that EAC h section addresses a separate concern.

This means, that we should

1. Identify the "concerns" that we need to take care of.
2. Decide where we want to handle them.

In other words, this principle would help us the identify the required layers and the responsibilities of each layer.

2. The Keep It simple Stupid (KISS) principle

The Keep It Stupid (KISS) principle states that:

Most systems work best if they is kept simple rather than made complicated; Therefore simplicity should is a key goal in design and unnecessary complexity should is avoided.

This principle is the voice of reason. It reminds us that the every layer has a price, and if we create a complex architecture that have too many layers, that's price w Ill is too high.

In the other words, we should not design a architecturelike this:

Source:geek and poke:footprints–licensed under CC 3.0

I think that John, Judy, Marc, and David is guilty of mental masturbation. They followed the separation of concerns principle, but they forgot to minimize the complexity of their architecture. Sadly, this is a common-mistake, and its-is-high:

1. Adding new features takes a lot longer than it should because we had to transfer information through every layer.
2. Maintaining the application is pain in the impossible because no one really understands the architecture, and the Ad-h OC decisions, that is made every, would pile up until we code base looks like a big pile of the shit that have ten layers.

This raises an obvious question:

What kind is architecture could serve us well?

Three Layers should is enough for everybody

If think about the responsibilities of a Web application, we notice that a Web application have the following "concerns":

• It needs to process the user's input and return the correct response back to the user.
• It needs an exception handling mechanism, provides reasonable error messages to the user.
• It needs a transaction management strategy.
• It needs to handle both authentication and authorization.
• It needs to implement the business logic of the application.
• It needs to communicate with the used data storage and other external resources.

We can fulfil all these concerns by using the "only" three layers. These layers is:

• The Web layer  is The uppermost layer of a Web application. It is responsible of processing user's input and returning the correct response back to the user. The Web layer must also handle the exceptions thrown by the other layers. Because The Web layer is the entry point of our application, it must take care of authentication and act as a first line O F Defense against unauthorized users.
• The service layer resides below the Web layer. It acts as a transaction boundary and contains both application and infrastructure services. The application Services provides the public API of the service layer. They also act as a transaction boundary and is responsible of authorization. Theinfrastructure services contain the "plumbing code" that communicates with external resources such as file Sys tems, databases, or email servers. Often These methods is used by more than a one application service.
• The repository layer is the lowest layer of a Web application. It is responsible of communicating with the used data storage.

The components, belong to a specific layer can use the components of the belong to the same layer or to the layer below It.

The high level architecture of a classic Spring Web application looks as follows:

The next thing that we had to do are to design the interface of each layer, and this is the phase where we run into terms Like data transfer object (DTO) and domain model. These terms is described in the following:

• a  data Transfer Object  is an object-is just A simple data container, and these O Bjects is used to carry data between different processes and between the layers of our application.
• a  domain model  consists of three different objects:
  • a  domain ser Vice  is a stateless class that provides operations which is related to a domain concept but aren ' t a ' natur Al "Part of an entity or a value object.
  • an  entity  is An object this is the defined by it identity which stays unchanged through its en Tire lifecycle.
  • a  Value Object  describes a property or A thing, and these objects don ' t has their own iden Tity or lifecycle. The lifecycle of a value object is bound to the lifecycle of an entity.

Now so we know what these terms mean, we can move on and design the interface of each layer. Let's go through our layers one by one:

• The web layer should handle only data transfer objects.
• The service layer takes data transfer objects (and basic types) as method parameters. It can handle domain model objects but it can return only data transfer objects back to the Web layer.
• The repository layer takes entities (and basic types) as method parameters and returns entities (and basic types).

This raises one very important question:

Do we really need data transfer objects? Why cannot we just return entities and value objects back to the Web layer?

There is and reasons why the is a bad idea:

1. The domain model specifies the internal model of our application. If We expose this model to the outside world, the clients would has to know how to use it. In other words, the clients of our application would has the to-take care of things that don ' t belong to them. If We use DTOs, we can hide this model from the clients of our application, and provide an easier and cleaner API.
2. If We expose our domain model to the outside world, we cannot change it without breaking the other stuff that depends from It. If we use a DTOs, we can change our domain model as long as we don ' t do any changes to the DTOs.

The "final" architecture of a classic Spring Web application looks as follows:

There is many unanswered Questions left

This blog post described the classic architecture of a Spring Web application, but it doesn ' t provide any answers to the R Eally interesting questions such as:

• Why the layer X is responsible of the concern Y?
• Should our application has more than three or less than three?
• How should we design the internal structure for each layer?
• Do we really need layers?

The reason for this are simple:

we must learn to walk before we can run.

The next blog posts of this tutorial would answer to these questions.

Understanding Spring Web Application Architecture:the Classic way--Reprint