Adam Ralph

Code, tea, and snowboarding

The All Solution

22 Apr 2013 Zurich

Once upon a time my team had all their code all nice and neat and all in one place. It was all conveniently located in one SVN repo in a single solution. This solution contained many apps which were worked on by some people who worked closely together and others only loosely connected in their day to day activities (a shared line manager but little more). I present to you the ‘All’ solution.

All.sln

What could be better? Less overhead since you don’t have to ‘maintain’ lots of SVN repos. Easier to locate code since it’s all in one place. Lots of nice reuse between applications. We know how to organise our code!

Sadly, nothing could be further from the truth.

The solution shown is for a fictional team named ‘HGC’ who develop fictional apps ‘Andromeda’, ‘Gemini’, ‘Jupiter’ and ‘Saturn’. The rest of the projects are so called ‘common’ libraries which are to be reused between applications. This is very similar to how my team had their code organised when I joined the team. In fact, our All solution was way bigger than this. Some of the problems with this approach are:

As we learnt more about DDD and also gained more exposure to OSS projects, we slowly realised that this approach made no sense at all. It was more driven by the organisation of personnel rather than the meaning of the code and the applications. Recognition of bounded contexts and integration patterns where necessary showed us that we were mixing separate concerns all into the same pot for no good reason. Imagine mixing unrelated OSS projects together in a single GitHub repo!

These days, each bounded context lives in it’s own repo containing a single solution. Any app which needs to talk to another uses a well defined integration pattern, e.g. Web API or message bus. Build times are down to minutes, if not seconds. Each app is nicely modularised, e.g. Gui, Console, Website, Model, Persistence, Infrastructure. We’re continuously innovating by trying new ways of doing things within the bounded context of a single application. Each application can evolve independently at it’s own pace. Of course there are still bits of mess here and there but it’s a different world now we’ve escaped the clutches of the All solution and the All repo.

Splitting our code into single bounded context repos and solutions was one of the best things we ever did for our productivity. If the ‘All’ solution and/or ‘All’ repo look familiar to you, consider breaking things up. I guarantee you won’t regret it.

blog comments powered by Disqus