How is your infrastructure layer holding up?

So how is the architecture of your software/web project holding up?
If you were to attempt the project again, from the beginning, would you change your approach?

This first came to my attention earlier this week, when a colleague approached, and asked if I could take a look at some major refactoring he had done over the weekend. Just to make sure he had not broken anything.

"sure, no problem!"

This was not a refactoring of code however, but of convention and architecture.

Some Background

Since this is a new blog, and I have not mentioned what I work on day to day yet. Let me take this moment to tell you a little bit about my day job.

tombola

I'm a web developer for a company called tombola.
A popular online bingo company, with websites to cover the UK, Spain and Italy.

The project

Without going into too much detail here. We use ASP.NET C# etc..
More to the point, we have 95 projects in our solution. This is to fully separate concerns and help us practice good software design.

The utility layer

The main issue was people using the common project almost as dumping grounds.
We found that when a dev wasn't sure where a piece of infrastructure functionality should live, it was being put into the common project.

Many applications make use of this pattern. Whether it is called Common, Infrastructure or something similar.
The idea is that the common project acts as a kind of utility layer over the application, which every other layer can consume.
Very useful for things such as extension methods or adding non business exceptions etc...

Problem

I think the word "common" can possibly portray a different meaning to different people.
When I look at the common project - I treat it as an infrastructure layer which can be consumed throughout the application, but is; itself unaware of it's consumers.
Others may look at the common project and think it's a place to put functionality which does not fit into a more specific location. This is bad. The common layer becomes polluted with references to other projects, projects it should not be able to see.

Another issue we found in the common layer was references to System.Web and other heavy dll's which it should not need access to; since it is not the web layer!

You may not see this as a big issue, but in ASP.NET MVC loading up all these heavy dll's when they are not needed increases build and start up time (which is the reason we went on a refactoring run in the first place).

Keeping your architecture tight

Make it difficult to do something you shouldn't be doing.

If you aren't implementing an architecture similar to the onion architecture - why not?

If you are unfamiliar with the principal of the onion architecture, Jeffrey Palermo wrote a very good 4 parter on the subject

Always write your classes as to not expose anything which could be abused in another assembly. By using tight constructors, backing fields etc... This helps keep your separation of concerns in tact.