I have been following Philippe Bourgau’s work for many years now. He has inspired me through his writing on agile, TDD, incremental architecture, and working at a sustainable pace. That is why I am immensely excited to have him write the very first guest post on The Serverless Mindset!

In this article, we get to look at a number of Domain-Driven Design workshops that can help us get the team aligned. These are especially useful as the team grows and greater alignment is needed.

For more content like this, make sure to follow Phillippe’s blog at philippe.bourgau.net and Event Storming Journal. You can also follow him on Twitter and Linkedin — Marco

Successfully building a serverless system as a team is far from easy. So, here are 3 DDD workshops for everyone to do collective and incremental architecture.

It's actually harder to do serverless development with two engineers than it is with one engineer. And [the problem] scales up ~ Nathan Taggart

Rise and fall of a serverless project

Imagine you've just started your new serverless project. Every commit you make is automatically pushed to production for you! It feels so productive. It's such a change compared to your previous job!

Fast forward a few months, the team has grown, and everybody is pushing to production. For better or worse, new Lambdas appear every day, making it difficult to keep track of all dependencies. Improved developer autonomy is turning into anarchy!

Fast forward yet a few more months. The system has become so tangled that it is now impossible to deploy Lambdas independently. Everything must be updated at once. You have built a monolith that is distributed on the cloud! Management has set up strict governance on the creation and deployment of Lambdas. Your previous job did not look so bad in the end!

Let's see how to avoid this horror story!

The middle way

The promise of serverless is to free development teams from most infrastructure work. Serverless systems are also meant to be scalable, cheap to run, and quick to update.

Unfortunately, as a team, things get a bit more complicated. Without enough coordination, it is easy to end up with a distributed monolith. With too much coordination, we end up with centralized, top-down, command-and-control management. Both extremes kill the serverless promises!

Wouldn't it be great if you could leverage your team's collective intelligence to build clean serverless systems?

Here are three workshops that will unlock agile architecture for your serverless system. And... one last thing, these workshops will also make work calmer and more effective!

#1 Big-Picture Event Storming

Big-Picture Event Storming is a whole-team workshop whose purpose is to visualize everything! It's about sticking all the domain events of the system on a giant design board. It's Domain-Driven Design in practice! It transfers tremendous knowledge between the domain experts and the developers.

Participants working at an Event Storming board

An architecture accelerator

Event Storming can achieve over a few days what would take months with traditional architecture. The idea is not to get a perfect up-front architecture. Instead, it's to design just enough for everyone to pull in the same direction.

Big-Picture Event Storming usually lasts between 1 to 3 days, and it scales well so that everyone can join. It works best when everyone is in the same room. However, it can work remotely with good preparation and adaptation. I wrote a guide about how to facilitate your first Big Picture Event Storming. If you don't feel like running one yourself, you can also ask a technical agile coach or a DDD expert for help. Yet, facilitating an Event Storming is a lot simpler than it looks, and it's a skill worth learning!

The first outcomes of Event Storming are:

Greater alignment so that everyone pulls in the same direction.
Better collaboration between the different profiles.
Agreed upon vocabulary that everyone can use when communicating and in the code!

Bounded Contexts

One crucial outcome of the Big Picture Event Storming is identifying Bounded Contexts. Domain-Driven-Design Bounded Contexts are the main functional areas of the system. Bounded Contexts provide excellent clues about splitting the code into coherent and independent sub-systems. Long-term, it makes the entire codebase easier to maintain and evolve.

Bird-eye photo of a Big Picture Event Storming where we can see the different bounded contexts delimited with strings of red wool

Identifying the Bounded Contexts opens many opportunities when building a serverless system:

When built around Bounded Contexts, teams are more autonomous and require less synchronization. (You can learn more on this topic in Team Topologies).
People have figured out that Bounded Contexts also make great candidates for microservices. (Remember How Microservices Can Help Your Team).
Bounded Contexts can help you focus your efforts on what is key to your business! You can agree on which bounded contexts are your business core that you should focus on (check Nick Tune's Visualizing Socio-technical architecture with DDD and Team Topologies).
You can even start defining APIs and protocols around your context services (if you want to learn more about this, check out Nick Tune's Business Model Canvas).
Bounded Contexts are also helpful if you are working on improving an existing system! The key is for everyone to align on a target architecture using Bounded Context. This alignment will influence the countless design decisions developers make every day.

Scope

Finally, the map of domain events is also a great way to negotiate the scope of the next increment to build. Just select events all along the chronology to draw your walking skeleton.

#2 Design-Level Event Storming

Many 'non-serverless' teams stick to Big Picture. Once the bounded contexts are identified, it's possible to adjust while coding. Yet, Design-Level Event Storming is very useful for distributed and event-driven systems.

That's why Design Level Event Storming shines for serverless!

A poster summarizing how the stickies can chain together in a Design Level Event Storming

Design-Level Event Storming comes after Big-Picture:

It's a way to 'zoom-in' a core bounded context.
It lets participants look into finer-grain Domain-Driven Design elements.

Design-Level Event Storming is an excellent activity to find the Aggregates in the system. DDD Aggregates are grapes of objects that enforce the atomicity and integrity of changes. They actually make perfect candidates for service APIs.

In serverless systems, Aggregates make good candidates for Lambdas. In How Serverless influences Design, Gojko suggests splitting serverless Aggregates even further. He relies on 2 reasons:

Cost: the smaller the Lambda, the more granular, the less it runs, and the less it costs!
Code independence: if the Lambda is small enough, it becomes easy to rewrite if needed!

During an Event Storming: everyone is in the room, and all the input and output events are on the board! There is no better time to split the Aggregates!

A photo showing how DDD Aggregates are visualized in a Design Level Event Storming. Blue stickies are the commands, orange stickies the output events, and yellow stickies represent the aggregate, each sticky being a business rule

Here is the essence of Event Storming: visualise everything on a board. It's a powerful way to ensure everyone sees all services and how they interact. As a result, it's one of the most effective tools to avoid building a distributed monolith.

If you have facilitated a Big-Picture Event Storming, drilling down to Design-Level is not too different. Here is a facilitation guide for getting you through your first Design-Level Event Storming.

#3 Example Mapping

The promise of serverless is that the cloud provider will take care of all the plumbing for you. This means that your lambdas should contain almost only domain-oriented code. Example Mapping is a neat activity to clarify the Lambda's business rules.

Example Mapping only takes 20 minutes, so you can run it very often. For example:

When starting a new user story.
Or after a Design-Level Event-Storming, to clarify what happens inside an aggregate.

Example Mapping is a structured conversation between Developers and Domain experts. Other specific profiles (e.g. quality engineer) can also join if need be.

It uses coloured cards to take shared notes during the conversation:

Yellow for the user story title.
Blue for business or domain rules.
Green for test cases that illustrate the rules.
And finally, Red for pending questions.

Example of the typical cards, colours, and layout that we use in Example Mapping (Picture from Cucumber blog)

Example Mapping is also an entry point to Behaviour Driven Development.

These note cards are easy to translate to executable tests and living documentation. Living Documentation is particularly useful for serverless: if your Lambdas are small enough, it becomes easier to rewrite than refactor them! Living Documentation tests will make this rewrite safe and fast:

They are written in a language that is independent of design or technology.
They are very stable in time because they rely on the domain only.

Example Mapping is straightforward to learn and simple to put in place. You don't even need to ask for permission:

Practice with a few colleagues.
And just take and share notes during an impromptu call with a domain expert.

Screenshot of a spreadsheet template that we can use to replace cards when running an example mapping over the phone

Finally, Example-Mapping is also remote-friendly. This post contains a spreadsheet template to replace cards during a video call.

Don't wait!

Are you involved with building a serverless system? Whether you are just starting or already deep in, you should run a Big-Picture Event Storming! It's a starting point that will lead you to Design-Level Event Storming and Example Mapping. These workshops will result in:

Alignment between everyone.
Just-enough architecture to keep your system healthy and to avoid centralized decision-making.

What about you? Do you know other workshops that are useful for agile serverless architecture?

Here are other workshops that are often helpful:

Flow Event Storming is a kind of retrospective. It's an opportunity to reflect on how the workflow fits serverless development. You can read more about how to run this workshop on EventStormingJournal.
A Test Strategy Workshop will help you take a high-level view of your testing strategy as a team. I have not written about this workshop yet, so ping me if you think I should! Both workshops will lead to improvement actions!

The Serverless Mindset

3 Wonderful Workshops That Will Make Your…