Last week, on Thursday 6th and Friday 7th of February, I attended DDD Europe 2020 in Amsterdam. In this post I will give a short overview of the talks and workshops I followed and some of my personal takeaways.
I had a great time on the conference. One of the things I like most is the mixture of talks and workshops. In the 2 hour workshops you are expected to actively participate in whatever is happening. Be it discussions or really doing some coding or testing.
I’d like to thank all the speakers and attendees for their input, talks, workshops and discussions during the breaks.
Dissecting bounded contexts - Nick Tune
Firstly, Nick started out talking about modularity and (domain) language. Modularity is something we apply daily in out lives. We divide books into chapters, countries into counties etc. We do this for different reasons, comprehensibility and parallelism among them. We do the same when trying to find bounded contexts.
However finding those boundaries is hard, understanding the business model, language and social technical architecture are all important in finding those boundaries.
It’s important to understand what is "core" and what are your "supporting" and "generic domains". Obviously most advantage can be gained in developing the core domain, but it also typically has the most complexity. And what’s core now, may not be in the core domain anymore over time. The world around us that influences our domain is constantly changing.
Language is also a key factor in finding boundaries. The phrase "Rock" mean something completely different to a musician and a geologist. We apply context to words and you should be aware that there already are linguistic boundaries.
Another important factor in dissecting contexts is the social technical context. Interaction between teams might allow or inhibit you to find boundaries. So being more dynamic in your team composition may be of benefit.
Evolving architecture with DDD and hypermedia - Einar Host
This was a nice talk about how we can utilize hypermedia as a means of expressing relations between context boundaries. Based on the notion that there are APIs that allow you to access information or services in your contexts, you can express links between them. Einar works for an online TV streaming company in Norway and gave some examples in how they used it. He also mentioned "Hypermedia Application Language (HAL)" as a means of expressing these links.
Personally, I like the idea of expressing links between contexts this way and will keep this in mind when (re)designing systems next time.
Architectural Decisions, a case study - Konstantin Kudryashov
This talks presented a case study of using Architectural Decision Records (ADR, link) as a means of keeping track of your architectural decisions and what you can learn from them as you do some retrospection over them from time to time. Although the insights may be partly specific to their system and use cases, some more generic insights stuck with me.
Learning is an integral part of the architecture. Sometimes you may have to re-evaluate your architectural choices and amend or revert earlier choices.
It’s OK to postpone some choices as long as you are aware of them. Make "postponing" choices a decision as well.
The team is a important stakeholder also. They are the ones who have to build, maintain and evolve the system supporting the business.
User story mapping for domain discovery - Trond Hjorteland
In this workshop we were introduced on how to use story mapping and use that to discover boundaries in your domain. We were given a use case of a TV/Internet provider that wanted to add more flexibility into the choices subscribers had in choosing their TV channels.
We worked in small groups to create our story maps, had some nice discussion, but never came to the point of modelling our domain. This was due to time constraints. Thus the workshop ended up being an introduction into story mapping. It’s now up to me to take this a step further.
A story of mob programming, testing and everything - Elisabeth Hocke
This was the final talk of the first day. Elisabeth (Lisi) took us along her personal journey of "mobbing". She explained what "mobbing" (programming, testing) is and how she used it within the company she works for. Setting up a mob isn’t that hard. Basically you need a room with a large screen, one computer and a group of 7 to 9 people (your team). There’s a driver who operates the computer, a navigator who directs the driver to do stuff, and the mob who ask and tell the navigator what they want to happen. All should be done with respect so that everybody can contribute and be heard. And than you take turn in being the driver and navigator. This can be time based or more naturals, for example when the implementation of some method is done. But it’s important to not make the turn to long.
One of the biggest benefits of mobbing is team learning and team growth. For me, this seems like a nice tool to add to the "developer toolbox".
Continued learning: The beauty of maintenance - Kent Beck
The opening note of the second day. Kent talked about coupling and cohesion. Some of the takeaways of this talk:
Coupling, in software, between systems etc. has a big impact on the cost of maintenance over time.
Decoupling is hard, but you can always find something to make things more cohesive.
As a best practice, separate structure changes from behavior changes and put them in separate pull requests. Behavior changes are generally irreverible (or expensive to reverse) and structure changes are not.
And his final closing mantra: Make the change easy and than make the easy change
Blink modeling - Cyrille Martraire
In this workshop Cyrille showed us how to model a domain within 2 hours. The domain he modeled was "HR Selection and Recruitment". Specifically the HR selection and recruitment within the Belgian government. Within the Belgian government they use something they call "evident based HR", which means they try to hire based on your credentials and achievements and be as unbiased about it as they can. A domain expert was interviewed and from time to time Cyrille explained why he asked certain questions. My expectation was that the attendees would do the modeling, but that was not the case. All we could do was ask questions and make some remarks. For me, this workshop had the least learning value.
Mob exploratory testing - Elisabeth Hocke
After the talk on Thursday on the subject of "mobbing", I wanted to experience it first hand. In the workshop 2 mobs and a view "mini mobs" were created. I was part of one of the bigger mobs. All the rules of mobbing were explained and we were handed some info of a Booking API. Now it was up to us to start testing this API. Not only technically but also more functional/non-functional. How we did that was up to the mob. So we ran the docker containers, used IntelliJ to create the API calls and used a mindmap to note our findings.
It surprised me how much work we got done in 1.5 hours with a team of complete strangers. Using IntelliJ to do HTTP calls was new for me, so I learned a new trick as well.
All in all, I had a good conference and have discovered and learned some new things. It’s now time to dive into them some more and see how they fit in my toolbox.