Boards in the Clouds – Part 2: Modeling with our team

As the name implies, the domain that will be automated with the software should be the driving force when building software this way. For designers, approaching a project like this is quite common but how do you accomplish it as an interdisciplinary team?

How does it work in practice?

You organize modeling workshops and invite everybody that has valuable input to your domain as well as the tech team. In other words you’re gathering an interdisciplinary team. The goal here is to…

• foster communication between disciplines as early as possible.
• learn collaboratively about the the domain that you’re trying to automate via software.
• shape and refine a shared model of this domain.

So you meet in front of a whiteboard and create a model of the domain that needs to be automated by software. There are different techniques that can be used to tackle such workshops, e.g. Event-Storming by Alberto Brandolini. I’ll just give you a simple introduction but you can read about all the details of this approach in Alberto’s blog post.

Identify commands & events

The first task for our team was to collect commands and events. These are the most basic building blocks that make up your application. Commands are the actual wishes and actions that can be triggered by the users. In our example, „note post“ was one of the first commands we came up with. The result of a command like this is an event, a fact that has happened. So „post noted“ seemed like a perfect counterpart.

You should be able to spot the difference between those two immediately. The command is using the imperative; it tells our application to perform a certain task. In contrast, the event is written in the past tense, because once the backend has decided to perform the command, an event will take place and cannot be made undone. To collect these building blocks, you simply write them down on post-its and attach them to your whiteboard.

Reach consensus & cluster into aggregates

The second step is to find consensus on the terms, verbs and subjects you’ve just collected on the whiteboard. You remove duplicates and settle on a common terminology. After that, you try to cluster these simple blocks into aggregates.

Aggregates are responsible for handling the commands and for making decisions based on their current state. Aggregates need to make sure that the rules of your domain are enforced. In our example: is the current user really allowed to note a post on this board? If the command is valid, aggregates will publish events in order to notify that a change has happened.

There are simple rules that you can stick to when doing workshops like this with your team…

• A model will always be an abstraction of reality, so don’t try too hard to find the perfect one on the first try. Instead, iterate and create variations. Test them out and gather feedback on what worked and what didn’t. There’s a tool that can help you with this called console.wolkenkit.io.
• This is not a one-time investment. Modeling workshops should happen regularly. Your model and your language should evolve just like your business does.

Obviously, this kind of collaboration involves a lot more communication than you’re used to – which can be challenging, of course. But when implemented by a team that’s willing to collaborate, share and learn, it can be rewarding; you’ll gain deeper insights into your domain. And it’s much more fun to build things together, anyway.

We believe this interdisciplinary collaboration is an important foundation for building sustainable technology as we move deeper and deeper into a world where software controls important aspects of our daily lives. This is an over-simplification of what DDD actually is and how it works. There’s plenty of information out there that lets you dig deeper into the details of this approach, e.g. by our friends at the native web.

What does the result look like?

In our example, the outcome of these workshops was a model that looked like this. There are currently two aggregates in our domain. The first one is a board that you can mount and share with others. By default, it’s only visible to the person that mounted it. The notes are actually a separate aggregate in our domain because we wanted to be able to collaborate on posts without causing conflicts when being edited in parallel. You note a post and afterwards it will be pinned onto a board. Once noted you can also move and edit this kind of post. In his book DDD Distilled, Vaughn Vernon shares other interesting tricks and guidelines for how to design a model such as this.

So what have we gained by following this approach? Together as a team we’ve designed a blueprint for an API without worrying too much about the technical details. We’ve had insightful discussions about our domain and we’ve settled upon a shared terminology to describe it.

We were quite happy with our first iterations and we were then eager to bring it to life.