When you start the development of your new software project you have some important choices to make. Some things can easily be changed later on but other ones are way harder to change.
That’s what Software Architecture is about. Making the decisions that will make sure the big picture is ok. Personally I really like begin a software architect. It’s an extremely interesting field where a lot can be learned.
In this blog I want to give a short description of the architecture I choose for Tiler.
Layers
One of the most basic principles in software architecture is to create a layered application where each layer has its own responsibilities. This helps in structuring your application and making sure that you are having a good separation of concerns.
The basic layers look like this:
You split your application in a presentation, business and data part. Each part only has access to the layers that are below it. This helps in avoiding spaghetti code where everything is connected to everything else. The crosscutting concerns, like security and logging, can be used in all layers.
However, is this really the best architecture you could dream of? Do you want to have your business layer to access the database layer Think of the steps you would have to take to move such an application to use a NoSql database? Or to switch from WebForms to a Single Page Application?
Thinking inside out
Jeffrey Palermo had a great post a couple of years back and recently he revisited the subject: Onion Architecture.
An Onion Architecture has four important characteristics:
- The application is built around an independent object model
- Inner layers define interfaces. Outer layers implement interfaces
- Direction of coupling is toward the center
- All application core code can be compiled and run separate from infrastructure
Why would you want to do this? For a couple of reasons. First it helps with keeping your code focused on what’s most important. You can focus on working on your domain and then define interfaces for all infrastructure services you need. Implementations of these interfaces live in outer rings. This points to the second reason. This setup makes it easy to change elements that live in outer rings without any effect on your domain model.
Focus on your domain and put most of your effort there. Change infrastructure elements when it’s necessary without affecting your Domain Model. That’s the promise of this type of architecture.
Putting it to practice
For Tiler I set out to try this architectural idea. For the base of my project structure I choose to use the Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App. I stripped some of the code to make things a little clearer. For example, I don’t have a distributed layer and instead of one Silverlight presentation client I have both a Windows 8 and ASP.NET MVC frontend.
I’m really happy with the current architecture. It’s loosely coupled and each layer can be tested on its own. I also tested how hard it is to switch my data access from the Entity Framework to RavenDB and even that worked very well. I didn’t have to make any changes to my other layers.
I would definitely encourage anyone to have a look at the Onion Architecture and give it a try. What is your opinion? Would you use this kind of setup in a large application?