These three letters were the focus of the meet-up on 9 June last at the Microsoft offices. Domain Driven Design: not a framework or a methodology but a software development approach driven by the domain. This is what the three speakers undertook to show us during this afternoon of live coding.
One wears the suit of a start-up manager, the other two wear the t-shirts of all-terrain developers doing paired programming to meet the start-up’s business needs.
The “techies” talk to the specialist in the business domain (here it’s a train ticket reservation platform), find the idea simple and the objectives doable (fix the bugs and add a new feature).
You’ll be familiar with what follows: they clone the repository, come up against the existing code, then revise their assessment…
‘Er, are you sure this code is for the business we talked about?’
‘I don’t know, I’m not a developer, I don’t know anything about code.’
I do know this application costs me as much to maintain as it did to build in the first place. I don’t know if it’s buggy and the cost of updating it from the previous team is exorbitant.
‘Are we talking about trains here?’ There is no field called train or even reservation.
There’s a Carriage class but that’s an adolescent class.
What is an adolescent class? It’s a class that has yet to take up its responsibilities, so it doesn’t contain any function, it’s a mere container.
It results in a catalogue of poor design, poor naming, anti-patterns, dead code, empty test plans etc. Ring any bells?
The developers tell the client that the project is not feasible and that it needs to be refactored. By adopting a new approach where the design is centred around the business. Where each class is responsible for a single behaviour and has the same name as the one used by the experts in the domain.
Step one: unit tests to ensure no loss … Install NCrunch in Visual Studio to ensure in real time that no portion of code comes to crash a function and to detect some bugs too.
Not everything will go without a hitch: the code is not totally testable: you have to mock up some components, create interfaces and set up dependency injection. And this makes you more aware that the expert in the domain cannot, at a glance, see how their application is behaving if they have to separate the system code from the domain code.
using (SqlConnection connection = new SqlConnection(connectionString))
A hexagonal architecture, as described by Alistair Cockburn, has been put in place. A hexagonal architecture is the opposite of a layered architecture, which makes you dizzy when you see the number of calls if you do a debug. This was widely used after the year 2000.
With the hexagonal approach, the domain code is at the centre and the infrastructure code sits around that.
The interactions are clearly identified by interfaces and pass through adapters.
So when an event from the outside world intervenes, it goes through its specific adapter, which transforms it into a procedure that the domain code can understand without knowing anything about the technical nature of the signal. When the domain has an item to send, it does it via a specific adapter that takes care of transforming the item to suit its own technology.
This means it is easy to run the program via a graphical interface, another program, automated tests or scripts and to develop it without having to take any peripherals or external components into account. And above all, that might help our boss!