Recently we fitted a 4-Tier Architecture in our project composed by the following four main layers :

  • User Interface Layer.
  • Data Access Layer.
  • Domain Layer.
  • Business Layer.

All the layers fulfill their usual roles in 4-Tier Architecture and interact which each one in the usual way. We use SVN to maintain our CVS.

My problem is that we have many inexperienced programmers developing in a well formed architecture, and we have to be checking all the time the code to find violations of the architecture.

For example:

  • Sometimes include access to database in the User Interface Layer and not in the Business Layer which is where interact with the Data Access layer to read or save data in the database.

Problems like the above occurs all the time. My question is:

How to check the code before the programmers can submit his new changes to the repository and report violations of the architecture? How to avoid doing this manually?

  • 2
    It's all about the Governance.
    – user53019
    Commented Apr 22, 2014 at 19:46
  • How good is the design? Are developers bypassing the architecture because it doesn't give them what they need? Commented Apr 22, 2014 at 19:49
  • @RobertHarvey No exactly , the design is very good, the programmers problems is that are newbie working with architecture designs Commented Apr 22, 2014 at 19:50

3 Answers 3


Perhaps what you're attempting is possible with Layer Diagrams.

See MSDN: Validate Code with Layer Diagrams

To make sure that code doesn't conflict with its design, validate your code with layer diagrams in Visual Studio Ultimate and Visual Studio Premium. This can help you:

  • Find conflicts between dependencies in your code and dependencies on the layer diagram.
  • Find dependencies that might be affected by proposed changes. For example, you can edit the layer diagram to show potential architecture changes and then validate the code to see the affected dependencies.
  • Refactor or migrate code to a different design.
  • Find code or dependencies that require work when you move the code to a different architecture.

You can validate code manually from an open layer diagram in Visual Studio or from a command prompt. You can also validate code automatically when running local builds or Team Foundation Build.

or Channel 9: Using layer diagrams to design and validate your architecture

This short video shows how to design architectural layers in your product, and then validate them to ensure that components implement the intended architecture.

  • 1
    This is interesting, do you know if there is an equivalent for Java or any JVM languages?
    – BrandonV
    Commented Apr 22, 2014 at 20:30
  • 1
    I am not personally aware of anything in the Java space, but there is this SO question that may help.
    – Eric King
    Commented Apr 22, 2014 at 20:57

If the UI layer has no access to the assemblies or authentication information needed to access the database, it is impossible to access the database directly from that layer. If you have separated your layers into separate assemblies, and limit the public data types and members to only those needed in the higher level layer, it is easy to detect a violation, as an assembly reference will have been added.

One problem pointed out by the user Euphoric below is that the assembly restrictions do not prevent lower layers from making calls into higher layers using interfaces, events, or delegate callbacks. So education about layering is still needed.

  • I disagree. What you suggest requires perfect abstraction of each layer, something that is utopia for any real project. It is much easier to teach the developers advantages of correct use of the architecture, than it is to develop perfect abstractions between layers.
    – Euphoric
    Commented Apr 22, 2014 at 20:50
  • 1
    I have personal knowledge of several very large systems that use exactly this sort of mechanism to prevent layering violations. It is not only possible in the real world, it leads to much more viable designs. Commented Apr 23, 2014 at 1:22
  • @Euphoric, this is standard practice, and a reason type visibility exists. If you have a specific problem, I would be happy to discuss it. I don't know what problem you are describing. Commented Apr 23, 2014 at 1:54
  • 1
    The reason why I don't like this is because developers (especially the inexperienced ones) are extremely creative in bypassing this kind of restrictions. For example, they might create a code that doesn't violate the assembly restrictions, but is still tightly coupled between layers. This tight coupling violates the reason why the layered architecture exist.
    – Euphoric
    Commented Apr 23, 2014 at 4:30
  • 2
    There are remedies for people who bypass encapsulation with Reflection. Commented Apr 23, 2014 at 15:28

There is only way to solve this problem: tutoring and core reviews. It is no-brainer that inexperienced developer's code is first reviewed by more experienced one before it is checked in. The reviewer then provides feedback, so the developer can fix the code and learn not to do same mistake again. And if said developer repeat same mistakes all the time, then it is time to look for a new developer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.