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.

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.

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.

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.

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".

The opening note of the second day. Kent talked about coupling and cohesion. Some of the takeaways of this talk:

And his final closing mantra: Make the change easy and than make the easy change

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.

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.