Feedback From the DDDx 2018 Conference

Last week I attended the DDD eXchange conference which took place in London, at a fabulous place called CodeNode. I had the chance to win a ticket thanks to a contest organised by the DDD Paris meetup. Kudos to them!

The tweet of luck.

It was my first time at DDD eXchange and I didn’t know what to expect, especially compared to DDD Europe that I attended twice.

Let’s start maybe by the most important. The conferences I liked the most listed by chronological order. Then we’ll continue with the few disappointments I experienced during this conference.

The conferences I liked the most

Marcello Duarte — Lean and Functional Domain Modelling

Coming from the PHP world, when the co-creator of PhpSpec is part of a conference schedule, you have to go. I personally use PhpSpec every working day, and I’m grateful to Marcello Duarte.

The talk was a summary version of the 2 days workshop he usually gives. It started with the importance of learning functional programming nowadays and a reminder about algebra and Algebraic Data Types. Then he presented a simple domain problem: a cafe which wants to reward its loyal customers. Marcello illustrated the modelling of this problem step by step, with Scala.

It was very interesting, but maybe too quick at the end (well, at least for me). This presentation made me want to dig further into Scala and to assist one of Marcello’s workshop.

Cyrille Martraire — Domain-Driven Dependencies

Ah, my favorite topic! Dependencies and coupling! The talk concerned all the classical aspects of this subject: independence from a service, independence from the framework and independence from the infrastructure. To achieve that, a developer has many tools in his box: inversion of control, hexagonal architecture, adapter, flyweight and bridge patterns, as well as the DDD strategic patterns with the knowledge of the downstream/upstream relationships.

Cyrille Martraire highlighted that in a downstream/upstream context, the direction of the relationship is not determined by the side which calls the other; but rather by which side uses the language of the other. He also made me discover the concept of “UML in color”.

Alberto Brandolini — Joys and Pitfalls of Collaborative Modelling

In this talk, the inventor of the event storming gave a lot of useful tips and tricks about how to accelerate the Darwin selection of a successful collaborative modelling. For instance:

• Try to sound stupid, even by asking obvious questions.
• Model out loud. Don’t just read in your head.
• Establish the “1, 2, 3, 4, flesh out something” rule during a modelling phase. Errors are better than blanks. Errors lead to discussions while blanks just lock the modelling process.
• Rush to the goal. Focus on the most important happy path first. Then and only then, explore alternatives.
• Don’t stop for alternatives. Use purple stickies instead and continue on the path you were currently exploring. Come back to the purple/problem stickies once this path has been investigated.
• Only talk about visible things.
• Raise the bar by not using a simple use case. Nothing valuable will come from a very simple example.
• Try some variations of terms, and see what fits the best.
• Take some breaks.
• Split the group if needed. Then compare both solutions. Discussions will be focused on what the two sub groups did differently.
• Once modelling has progressed, use the “3 minutes silence” round. To make everybody think about what they have achieved.

Ultimately, people and personalities are what matter the most. And collaborative modelling is all about diversity and respect.

As always with Alberto Brandolini, I didn’t see the clock ticking. I warmly recommend this talk for every person that tries to facilitate an event storming session.

Cyrille Martraire — Interviewing Domain Experts: Heuristics from the Trenches

The embodiment of the French accent, round 2. Cyrille Martraire substituted Greg Young who couldn’t attend DDDx. And honestly, I was not disappointed. This was, in my opinion, the best talk of the whole conference. Since I read Nick Tune and Scott Millett’s Patterns, Principles, and Practices of Domain-Driven Design, and took note of the “powerful questions” to ask to domain experts, I have been looking to know more about it; without any success so far. This was the first conference I’ve seen that dealt with the topic.

A few heuristics and tips given by Cyrille Martraire:

• Learn about the domain before the interview. There are books for every domain.
• Ask a precise question to start a conversation. For instance, “I’d like to understand how an insurance policy works”.
• Apply active listening. Don’t change words during note taking.
• Don’t interrupt, take notes for later.
• Underline every new term, to be able to ask questions about it later.
• Try to find differences (or not) between terms that look similar.
• Establish credibility with sentences like “I know that xxx, but…”.
• Ask for sample documents/data.
• Best way to get the right answer: propose something wrong and let people correct you. Because people are happy to correct you.
• Use your past knowledge into your new domain.
• Note when the answer is not convincing.
• Come with printed screenshots of the current running application.
• Never think that you’re smarter than the expert, even if you know well the domain. Always ask for validation.
• Better conversations happen in cafes and bars. Not in meeting rooms.
• Ask key questions. Like: “Is it always true? Is there a case when it’s not true?”.
• Most of the knowledge is tacit. Extract it with questions like “What if… ?”
• Several domain experts together may lead to confusion. Or possibly be the sign that several bounded contexts are in the middle the conversation.

Bref, vraiment, merci Cyrille !

Mathias Verraes — Design Heuristics

Last talk of the conference, and the one I was expecting the most, as Matthias Verraes is one of my coding heroes. I learnt so much from his blog posts a few years ago. OK, enough sentimentalism. Let’s go back to the talk.

Well, it was not a talk per se, but more of a kind of giant participatory exercice with the use of a whiteboard and sticky notes. Matthias Verraes presented briefly three pieces of software and how they were linked together. Something similar to this:

What comes to your mind when you see such a model?

Three stickies with an Invoice, a Payment and a random Payment Behavior. We didn’t know much more about those services or contexts, but it was not the point. When we work on a model, like this simple one defined by three stickies, we try to answer questions such as:

• Should we improve it?
• Can we improve it?
• Does it fit our problem?
• What can we deduce from it?

The goal of the exercice was to cogitate about all heuristics that we usually use during our modelling sessions to answer those questions. Often, we answer naturally, thanks to our previous mistakes or our past experiences, without even thinking how the response comes.

With the help of the crowd, Matthias Verraes highlighted a lot of modelling heuristics that we use on a daily basis as developers. Among them:

• Draw boxes and arrows: if you end up with a circle, you surely have a problem.
• Check the direction of arrows.
• What about changing the direction of arrows?
• What about removing an arrow?
• Push vs pull. Who will trigger the communication?
• Events. What happens in the system?
• Use examples. Does the model reflect reality?
• Look for look alike, but are not alike.
• Temporality. How does the system behave during time?
• Should the publisher ignore the needs of a consumer?
• Lifecycle. What are the different states/phases of the system?
• Code ownership. Who is responsible of this part?
• Rate and source of change. Does this part change often? Who is responsible of those changes?
• Extract and share. Can a sub-part be taken out the system to simplify it overall?
• and much more…

All of this should, of course, not be considered as rules to follow. But they are questions that should be asked or clues that could be explored to try to improve a design.

To be honest, it wasn’t exactly what I expected of the presentation. Actually, it was way better! Especially with the active participation of the audience. This is definitely something I’ll think about more during my next modelling sessions. As Matthias Verraes suggested, I’ll try to create my own modelling heuristics’ box.

Just a few disappointments

The unconference

worThe unconference, a free slot where people can talk freely about whatever they want, is a great idea. And it was very well organized. Sadly, a lot of persons already left before it began. Also, the result of such talks will considerably vary depending of the group you are in. Too few people could lead to not enough diversity in the conversation while too many people could lead to boredom, as not everybody is able or has the time to talk (which was my case). Maybe a good solution would be to limit the number of persons per topic?

Crowd/speakers, all developers?

Same assessment as for DDD Europe. Maybe I’m totally wrong but I have the feeling that the very vast majority of people is made up of developers (or software engineers, software crafters, architects, software coaches, you name it). I’d like to see more variety: product owners, domain experts, product managers. More importantly, I’d like more topics focused around the dynamics of creating a software within a mixed team.

But perhaps it’s not the intention of a DDD conference, and I should look for something else. As it’s an important topic to me, I’ll dig more into those those questions in a coming post.

Conclusion

DDDx London 2018 was amazing! The conferences I’ve attended, the warm atmosphere, as well as discovering this vibrant city of London. Everything was great! Thanks to all the speakers, to the people I’ve talk to and to SkillsMatter for the organization. Most of the talks are already viewable here.

It was so good that I already bought my early-bird ticket for next year. See you next year DDDx!