How do you go about creating good software? There are so many approaches and models out there. But one thing is clear: “Not worrying about the design doesn’t mean that you don’t have any design at all. It means that you have a bad design.” I don’t remember where I read that quote but I do know that it’s alarmingly accurate. And that’s why here at allmyhomes we decided to follow the domain-driven design (DDD) approach, with the plan to roll it out across
the whole company and get it firmly established.
The term “domain driven design” (DDD) was coined by Erik Evens in his book of the same name back in 2003. DDD is an approach to software design that is bang on trend right now. As is so often the case when things are hyped up in the IT sector, you will often see DDD advertised as some kind of miracle cure. And that is why it is so important to take a critical approach to DDD. But first of all, I want to take this opportunity to break down what DDD is all about in simple terms:
“Complex business problems need to be presented to developers clearly using business jargon and covering every relevant business context so that the software created in the end is a solution that uses the relevant business jargon and reflects the same context divisions in its structure. Domain-driven design provides a range of tools and terminology that can be used to identify core processes, contexts, and dependencies and make decisions critical to software design on the basis of real business requirements.”
You can see that we are moving from a solution-based approach to a problem-based approach here. In other words, the IT team is not given the task of implementing a specific solution. Instead, they are asked to find
a suitable solution for a certain problem and then implement it. This requires much closer communication between the teams on the business and IT side.
If a company decides to roll out DDD, employees need to change their mindset quite considerably. IT staff can no longer hide away and those on the business side have to move beyond the tendency to view IT staff
as service providers.
When allmyhomes decided to go for DDD, the move was being driven on the IT side. As is often the case when new processes are implemented, acceptance and knowledge sharing are among the aspects that need
to be considered from the outset.
Meetups are a fantastic way of sharing knowledge internally, drawing on external knowledge, and starting up discussions with anyone who is not fully convinced by the change. Knowledge can be imparted in a good presentation and everyone soon gets chatting over a drink and a snack.
On the day of our meetup, we had a full house. The topic certainly seemed to have struck a chord. Out of 100 registrations, around 40 people showed up, putting the attendance rate at about 30%. We were also joined by some 20 employees from allmyhomes, meaning that every last seat in our lovely lounge was taken. Our fantastic organizers made sure that we had everything we needed, leaving us to focus on the presentations.
And we have to say that both presentations went down very well indeed. Károly’s approach was rather special, as he had relied solely on distinctive pictures and not included any text. His presentation was easy to follow and the images really added to what was being said at the time. I had decided on a cowboy theme, with a title inspired by “The Good, The Bad and the Ugly” and plenty of videos to capture the audience’s attention. We were asked plenty of relevant questions after the presentations, which got everyone talking no end. The audience was made up of developers alongside some POs and project managers.
All in all, the meetup was a huge success. We saw DDD get another boost and the external input helped us change a few mindsets. Obviously, there is no guarantee that hosting a meetup like this will prove successful for companies looking to roll out DDD. But if it’s planned carefully and generates enough interest, it might just help people come to terms with the change as well as providing a good opportunity to share information.