DevMountJob is an example of a web application developed using the Domain-Driven Design approach. We start with the strategic DDD by running three Event Storming sessions. Then, we switch to the tactical DDD where we use its patterns to implement discovered models. Moreover, we use CQRS to clearly separate the domain from the read model. Finally, we use Event Sourcing as a persistence mechanism. Such "all-in" approach allows us to approach clean design and it also has an educational purpose, as you can see all these fancy, highly abstract concepts used in practice! Have fun!
This repository arose from a series of posts, so you will gain maximum knowledge when you read them and analyze the code. Below you can find the current list, which will be updated when a new post arrives:
- "See how I failed at my SaaS idea and what you will gain from it." - a crucial one, as you will find there a detailed domain description, and knowing the domain in Domain-Driven Design is well... crucial ;)
- "The story of how to NOT start a project." - this one is rather optional but it sheds some more light on how I failed actually. It can help you avoid some mistakes while working on your side projects.
- "This could be the biggest post about Big Picture Event Storming ever! And with examples!" - we start crunching the domain knowledge here. You can't miss it.
- "Process Level Event Storming: let’s get this process started!" - modeling sub-processes that will address our business requirements and issues.
- "Design Level Event Storming with examples!" - proposing some designs for our solution.
- "My first event-sourced aggregate in Ruby…" - the first post about the implementation, CQRS, Event Sourcing.
- And the following ones - TBD.
Subscribe to my newsletter and be up to date with all the new posts!
DevMountJob is a SaaS that would reverse the flow of the typical hiring process. The idea behind it, in general, is to have a developer job board (and not any other one). In other words, it is a place that doesn’t list job offers but instead, it is developers who look for them. A place where a developer could put up an anonymous notice, delineating their own terms and conditions and presenting their technical profile without including details such as employment history or educational background. Eventually, I failed to launch it (see the mentioned post for more details). Nevertheless, now at least we have an open-sourced project from which we can learn how to design and implement a project in a DDD approach and use the state of the art tech stack ;)
When I was developing this project for the first time, I wrote an article about the whole idea, my thoughts, and solutions to fix the broken hiring process. The post is still available here. It's pretty long, old, and not essential in the context of the project here, but it can show you the big picture. The first post of the series might be more interesting for you, as I describe the domain in detail and why I want to share my experiences. This one is crucial if you want to understand the project's code in this repository and gain domain knowledge.
DDD is not about using a set of defined patterns - it's about exploring the domain, finding boundaries of its subdomains and processes and designing models that are going to support our business processes. We somehow need to gather domain knowledge. The perfect way would be to spend a lot of time with domain experts on a daily basis. Nevertheless, we may sometimes have issues reaching them, or the knowledge could be distributed between a few people. Fortunately, we can use some tools to help us with knowledge crunching. Event Storming could be such a tool.
Event Storming is actually a set of workshops that usually consists of:
- Big Picture Event Storming (BPES)
- Process Level Event Storming (PLES)
- Design Level Event Storming (DLES)
I did all of them for this project and documented them in the greatest detail.
In this one, we want to see, well… a big picture of the business process – we want to catch a sight of participants'
perception. As I wasn't familiar with Event Storming too much, I asked three experts to help me with BPES: Mariusz Gil,
Łukasz Szydło, Andrzej Krzywda. Each of them has
vast experience in programming and gathering business requirements from customers.
It would be most beneficial if you read now the third post
of the series to see how we ran the BPES on this domain.
We ended up with something like this:
Here we need to climb down and model sub-processes that will address our business requirements and issues.
Back in the BPES workshop, we noticed some smaller, autonomic sub-processes within the whole process. Now we can
focus on each of them and take care of the details. PLES gives us a few additional elements that will help us in this job.
These elements are: read model, command, system, policy.
To get more details about the PLES you need to read this post.
It's the cherry on top. You may not believe it, but we are going to... design here. We are going to propose some models
that will support processes identified during PLES. You will find all the details about how I did it in
this post.
Even though I'm a Java fanboy, I decided to implement this project in Ruby. In the first post about the implementation I describe it in greater detail and also talk about the motivation behind it. I also explain some concepts like CQRS and Event Sourcing there. To sum it up, I find the Rails Event Store very easy to use, and it helps to focus on the business logic and not on the glue code for commands and events. I also know Arkency's approach to DDD, and it resonates with me. Last but not least, Ruby was on my to-do list quite long, so here I am.
Now, browse the code, run some tests, play with it! If you find anything that you would do in a different way, just fork the repo, do it, and don't forget to share it with me. Found a bug? Fix it! :)