The obvious architecture

Somewhere in the 7digital.com web site infrastructure there are classes that override the default controller and view factories (it is an ASP MVC project). Why did we do this? In our opinion, the default project layout is a hindrance to code readability.

The idea is explained by Uncle Bob in his concept of “screaming architecture”. i.e. if you glance at the program's folder structure, what is the most blatant thing about it, what is it “screaming about”?

If there's a folder full of controllers, and a folder full of views, and another for models, then it's screaming “I am an ASP.Net MVC project! I do ASP MVC things!”. If there's a folder called “Artists” and another called “Genres”, each containing controllers, views and other classes related to that feature, it's instead saying “I am a music catalogue on the web”.

I personally feel that “screaming architecture” is a very poor name for a very good concept. The architecture isn't having a crisis. It's not running around with hair on fire shouting “aaargh!!!”. Maybe Uncle Bob has more positive associations with the word “screaming”? With his meaning of “screaming”, every architecture is screaming about something, but what is the important thing.

I'd prefer something nicer sounding like “obvious architecture”, “lucid-domain architecture”, “feature-folders architecture” or “grouping related things together for readability architecture”. You can debate what is and isn't “obvious” but IMHO there's a far smaller range of ambiguity to that word than with “screaming”.

With ASP MVC projects, the default layout is all controllers in one place and all views in a different place. This isn't a problem with small projects, but the overhead of tracking what relates to what grows larger as the website grows. For instance, the Customer Controller would live in “/Controllers”, have views in “/Views/Customer“, models in “/Models“ and since we write good, single responsibility classes, there are classes that handle the controller’s requests in “/Code/Customers/“ . Working on customers touches all of these.

It is better to group these customer-related classes and views together in one folder, say “/Features/Customer”. Changes that span multiple files will now generally affect files in the same folder. And the tests on the customer use-cases will be in a different project, but also in a “TestProject/Features/Customer” folder. Opening a project – even a simple one - with the default layout now feels more difficult, with unnecessary jumping around to locate the parts of one feature.

The 7digital main website started out with the conventional ASP MVC layout. But as it grew, this became harder to deal with. The feature layout was not easy to get in place - and some people didn’t see it as important. It was engineered (with the spark view engine not razor) and the code refactored over a long period of time before I started with the company, mostly by Raoul.

But now that we have the benefit of this experience, I’ll certainly start new projects this way, and you can too. Other web frameworks such as ServiceStack, Nancy and OpenRasta are more flexible about folder layout and encourage organisation by features. You can only choose one organisation of files in folders on disk. You can choose to put files with the same type together, or you can choose to put files with a related purpose together. But the computer will find it very easy to find all things of the same type (be it “file name ends in “.cshtml” or “class inherits from Controller”), and a lot harder to extract meaning from the files in order to find classes that are meant to work together. So we add value if we build the meaning in - the arrangement that is hard to grep for later is the one that we make clear at a glance.

The ASP MVC “areas” feature isn’t a very good solution to the problem - IMHO it’s not granular or flexible enough, with too much framework ceremony overhead.

ASP MVC feature folders are but a small application of this idea, they aren’t the total of the “screaming architecture”.

For large features, you’re going to move related code out of the web project and into other projects in the same solution (or even further, to packages or services). This encourages a design of layers not features. It’s more of a judgement call here which organisation to use when.

Some javascript projects I've seen go a step further and put the tests in the same folder as the feature. The build process and test runner is then responsible for distinguishing between them. This means that the feature in its entirety is contained in a single folder and can then be re-used by copying that single folder. You can see something similar with client-side angular.js modules explained here.

For ASP.Net MVC, the technical details of the classes that override the default controller and view factories to find them in non-default locations are: 1) Actually the WindsorControllerFactory just does this for controllers with no extra code required. 2) It's less simple for razor views, but you can start reading about it here on Stackoverflow.

Today marks the beginning of the Technical Academy Tour as Academy Coordinator, Miles Pool, VP Technology, Paul Shannon and later, former apprentice, Mia Filisch head out across the UK to talk about our Technical Academy.

Continuous learning has always been part of the culture at 7digital and the Technical Academy allowed us to focus those ideas and start hiring apprentices. Changing the team entry requirements and providing a defined period of training allowed us to attract people from more diverse backgrounds and has increased the proportion of female developers in our team; it’s also strengthened the culture of learning and knowledge sharing at every level.

Since I started at 7digital I’ve loved our belief in continuous improvement. Throughout our history as a company we have had a number of influential women working in various parts of organisation yet I knew there was more we could do to improve the diversity of our tech team.

Here at 7digital, we see the relationship between the customer and the developer as one of the most important aspects of software development. We treat software development as more of a craft than an engineering discipline. Craftsmen back in the day would have constant communication with their customers, receiving regular visits from their customer to discuss progress and alterations as the item takes shape.

Over the last twenty years, the agile software movement and extreme programming in particular has championed this with its short iterations, customer showcases and active customer participation in the creation of features.

7digital software developer Mia Filisch attended the October 28th Velocity conference in Amsterdam. She was kind enough to share her account of the core takeaways here with us. She found that the core recurring theme around security was enough to inspire some internal knowledge sharing sessions she has already started scheming on. The diversity of insights led to a productive and informative conference. See below for her notes.