DEV Community: André

Using F# and DDD to create an online card game [On hold]

André — Tue, 30 Jun 2020 02:43:40 +0000

This would be the third post of a series of posts about domain-driven design and functional programming with F#. Last week was crazy and I didn't post anything and it was difficult to study DDD too.

Even though the third post was almost done, I decided to put this series of posts on hold for some days. The reason is that I noticed that, since it's my first time studying DDD, I still need to re-read some parts of the book to understand them better before continuing with the implementation otherwise I will get confused (and also confuse others) by forcefully writing something.

Since I'm writing this series primarily for myself, I won't bother pausing it for now. I'll continue the studies and then I'll start posting again as soon as I understand it a little bit better, maybe next Monday.

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

André — Tue, 16 Jun 2020 22:04:13 +0000

(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?

Using F# and DDD to create an online card game

André — Tue, 16 Jun 2020 19:50:35 +0000

(this post was imported from Medium)

In the last days, I have been studying a book that sparkled the beginner's excitement in me — a feeling that was a long time gone. The book is called Domain Modeling Made Functional, written by Scott Wlaschin, and is about using a functional language to design software following the principles from Domain-Driven Design (DDD).

DDD and F# made me realize that there's still so much that can be done to improve the quality and reliability of software that we write.

"Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain."

A nice quote from Domain Modeling Made Functional about DDD:

"If you think of software development as a pipeline with an input (requirements) and an output (the final deliverable), then the "garbage in, garbage out" rule applies. If the input is bad (unclear requirements or bad design), then no amount of coding can create a good output.
(…) we'll look at how to minimize the "garbage in" part by using a design approach focused on clear communication and shared domain knowledge: domain-driven design, or DDD.

Since I know that the best way to learn is to practice what I'm studying, I challenged myself to write an online version of a simple but very nice card game that I play with my friends.

The game is called Dutch Blitz and I see it as a "multi-player solitaire". It's important to notice that this is a study project and I don't intend to make any money with this game.

In order to register my progress, I decided to write a series of posts about the theme.

What are the technologies that I want to learn in order to build an online version of this game?

F# in the server
Elm in the client
Websockets
Azure to deploy the code (because I'll use F#)
Whatever else I need to build multiplayer games (I’ll edit this section as I learn what these things are)

The initial goals for this game are:

[ ] Have a pure (no side-effects) functioning engine tested with TDD. I'll use DDD to model the domain.
[ ] Have a functioning real-time multi-player state handler
[ ] A simple, four-player, UI
[ ] other stuff that I'll write as soon as I figure more things out

I won't spend a lot of time thinking about the architecture in the first moment. I'll think about it only after I have modeled the game domain.

Since I'm a beginner, I expect to make wrong assumptions about the domain and to use DDD/F# in the wrong ways many times as I learn and make progress. But it's ok! Learning involves making mistakes.

Every Monday I'll release new posts. Stay tuned :)