In most of my projects, I’m using or I’m trying to introduce patterns from Domain-Driven Design, Event Sourcing, and CQRS. Most of those patterns are somehow related to the publish-subscribe pattern and it’s not possible to efficiently use them without it. I’m working with Ruby on Rails and my choice is RailsEventStore. Of course, it’s possible to implement a very basic mechanism by ourselves, but if we can use a well-tested solution then why not use it. The general idea behind this article should be applicable for every tool but in the examples, RES will be used.
Let’s start from the beginning. We start a new project or maybe we want to extract our first bounded context from existing legacy code. We need to add event store configuration to the project. …
Recently one of our clients asked us to improve the registration process in the mobile application. The current solution is based on text messages and deep links. Users need to click on a link in a text message to verify the account and be redirected to the mobile application. This solution has a few disadvantages:
- It’s old. It was popular a few years ago.
- There are many problems with deep links handling on the mobile application side. …
This is a rather common situation in my projects. We have a back-office web application to give our clients the option to manage mobile application content. The specification is very similar between projects. There are many tabs, tables, and plenty of big forms with 10 or even more attributes. It’s a common practice to combine unrelated attributes into one huge form with one save button. That leads to significant differences between UI and our domain.
Today we will talk about how to fit this into Domain-Driven Design patterns. At first, it may look like there is no problem. We can create one big command with all attributes received from the front-end via API and pass it to the command handler. Unfortunately in most cases, attributes are related to different domain models and we need more than one command to properly handle this situation. We can also have a situation where all attributes are from one domain model but there is no strong connection between them e.g., avatar and password. …
Most of the projects I’m working on right now are related to mobile applications and Ruby on Rails backend. Today we will talk about what needs to be done on your server to support mobile ‘Sign in with Apple’ feature. Our goal is to create a simple API that will allow registration and login process to our system using Apple account and mobile application.
The first thing we need to do is to read the documentation to know if there will be any communication between our system and Apple servers and how to implement it. …
We have started the third week of the class and this week we are learning about tactical patterns in Domain-driven design for instance, Value Object, Entity, and Aggregate. In addition, as part of our homework, we have started implementing our first Ruby on Rails application with DDD, CQRS, and Event Sourcing.
Let’s start with Value Object.
What is Value Object?
Value object is an immutable object without any history or distinct identity. It is represented and compared by value (combination of its attributes). If you want to change value object you have to create a new instance with new attributes.
Let’s stop here for a moment and try to visualize this concept. We can think about numbers. A number is represented by the value for example, 9. We do not have any additional identity here. We can add two numbers and we will get a completely new number for example, 9 + 1 = 10. When we are looking at 10 we do not have any history of changes, we do not know if it was created by adding 5 + 5 or maybe 2 + 8. …
In my last blogpost about bounded contexts, I mentioned technique called event storming. Here I want to present more details and explain how your team can benefit from it.
Event storming was proposed by Alberto Brandolini and can be described as an interactive workshop with a lot of sticky notes. It can be used to achieve different goals from designing event-driven systems to better understating underlying business processes in your domain.
Before you can start you need a few things:
- At least 4 different colors of sticky notes. …
In the first week of the course, we had an introduction to the idea of bounded contexts. Currently, in the second week, we are learning more details about this concept and how to apply it in real-life projects.
Bounded context is one of the strategical patterns in Domain-driven design. Most projects are split horizontally as you can see in the image below and it’s called layered architecture. We have different layers for business logic, presentation, and persistence. Number of layers depends on a project but the main idea here is to group our components/classes inside those layers.
Recently I joined a new online course Rails Architect MasterClass organized by Arkency. You can see the whole description in the link above but, in brief, the main goal is to learn techniques related to Domain-driven design, CQRS, and Event Sourcing. After this, you will be able to use those techniques in new projects and existing legacy code base.
The course is divided into 12 weeks. Each week is about a different topic with lots of materials and exercises to do. In this mini-series, I will try to post at least one blogpost per week about current topics, what I’ve learned and if I like it or not. …
About
