Server-side Architecture Validation

This is the eighth blog of a series of posts about the topics Continuous Integration and Continuous Delivery. It explains how important continuous integration is to deliver software in short iterations to the customer with a high quality standard.

The architecture layer diagram is one of the best features in Visual Studio. It gives an easy and great possibility to validate the defined architecture. There are a lot of applications which started with a well-defined architecture and a lot of thoughts and ideas behind it. But over time when the code is getting implemented, refactorings are done and time pressure comes up, the defined architecture is not followed anymore. It takes a lot of time to review the dependencies between the layers and assemblies during the development phase. Sometimes reviews point out that some unwanted assembly references have been added to the projects but this reference is already heavily used and it takes a high effort to get rid of it again.

The Visual Studio Validation Layer Diagram this mentioned problem can be solved or at least reduced.

How to create a Server-Side Validation Layer Diagram?
The following article explains how to use the Validation Layer Diagram in Visual Studio 2010. It even explains how to enable the Layer Validation in the CI Build and to reject check-in's which do not follow the defined architecture. This helps that the code which violates the layer definitions is not committed to the main branch and does not cause a lot of headache and effort to get fixed at a later point of time:
Favorite VS2010 Features: Layer Validation

Which layer diagram views should be created?
Here is an architecture project which defines different views on the applications and components. It is an example project which givens an idea which different views can be created.

Usually, the following three views should be at least defined in the Architecture Layer Diagram:

• High-Level View (Overview.layerdiagram)
• Second Level View - (Presentation.layerdiagram, ServiceLayer.layerdiagram, Business.layerdiagram, DataAccess.layerdiagram)
• External Components View - Restricts the access to external components (ExternalComponents.layerdiagram)

High-Level View (First Level View)
This view defines how the different layers depend on each other. This is the most important view of the application and should be defined already during the project set up together with the assemblies. It is very important to keep this view up to date because it has a high impact on the maintainability of the solution. Here is an example how this high-level view can look like.

Second Level View
This view explains the internals of a single layer. Usually, there is at least one diagram per layer. If a layer is quite complex there can be even more diagrams. The following figure shows an example layer diagram for a Data Access Layer.

External Components View
This view is also very important because it restricts the layers / assemblies to use a defined set of external libraries. It helps to keep external code isolated by defining the exact places where a library is allowed to be used. It solves the problem that special API calls are spread over the whole applications. A good example is for instance the Entity Framework which should be just referenced and accessible from the Data Access component.

After defining the dependencies and configuring the gated CI Build, it is not possible anymore to check-in code which is against the basic architecture. The build process shows an error if a layer break happened even before the code is committed. In this example a call from the Web Application (Presentation Layer) directly to the Order Repository (Data Access Layer) is not allowed anymore: