Using F# and DDD to create an online card game[Part 2]

(this post was imported from Medium)

This is the second post of a series about domain-driven design and functional programming with F#, based on the book Domain Modeling Made Functional. You can read the intro here. Disclaimer: This post won’t contain any code. We’ll start to see some code in the next posts.

---

I’ll start to model the domain in a way that a non-technical person can understand. This can be done by creating a shared understanding of the domain. There are some techniques that can be used to achieve this understanding and the first one presented in the book is Event Sourcing.

Ideally, it should be done in a meeting with some domain experts and the development team, but I’ll use online content to help me create a shared understanding. There’s a nice video explaining it too.

I’ll start by creating the domain events that can happen (I might add more later since my understanding of the domain can still evolve):

We might think about what makes these business events happen. An event might be triggered, for example, by a player that placed a card, or by someone trying to join the game.
We will call these things commands. These commands might fail (for example if a game cannot be joined), but just as the book does, we won’t bother trying to think about it now. Not all events will have commands associated with them.

A command always initiates a corresponding business workflow — a function with an input and an output. I will omit the workflows’ boxes to save some space in the timeline.

So now we have created the commands that trigger the events. For example, when a player commands to “Join Game”, a “Join Game” workflow is executed and it then produces a “Player joined game” event. The “Place Card” command will always trigger the “Card Placed” event but it can also trigger two more events depending on the player’s blitz pile and overall score.

---

After listing the events and commands, we can create the bounded contexts and the context maps. I think we could create a “Game creation context” and a “game validation context” but since I think it would be an overkill, I will skip this part and revisit it later. For now, I’ll consider we have only one bounded context.

A note: bounded contexts can be good indicators of microservices that can eventually be created.

---

Since I didn’t have much time to work on this game yet (the first post was two days ago), I will keep this post short. Next Monday I’ll have more interesting things to talk about.

But what do you think? Have I listed all the events properly? Can I improve the events and the commands?