A very technical issue: on DDD and the design of complex systems
In the latest podcast “Dry the oars” discussed methodologies for designing complex systems. We talked a lot about Domain Driven Design, Event Sourcing and CQRS. The topic is not easy, but, as they say, very interesting.
Artyom Kulakov and Roma Choryev are the developers of Redmadrobot, they record a podcast where they discuss various aspects of creating IT products. Below is a link to the new episode, timing and answers to heartbreaking questions. But first, a little disclaimer:
Why is there more and more talk about different aspects and methodologies of systems design? Because our systems have gotten really big. To figure out how to design such systems, we called Alexey Merson, a system architect from Karuna. In this issue we tried to figure out what Domain Driven Design is, how it is related to Event Sourcing, and what does CQRS and microservices have to do with it. Only the first layer was removed, and even then it was uneven. But for everyone who wants to start diving into the topic, this issue will undoubtedly be useful. And be sure to check out the release notes.
Timing
02:29 – Guest of the studio Alexey Merson and how he started;
05:02 – .Net and DDD;
12:26 – why are they talking about DDD more and more often;
15:30 – useful literature about DDD;
23:01 – how to start designing a DDD system;
25:05 – Event storming and Miro;
45:15 – what is Event sourcing;
55:00 – CQRS and its relationship with DDD and Event sourcing;
01:06:10 – where to start.
DDD – what is it and why now?
Domain-Driven Design – Domain Driven Design. The concept has been known for a long time, but recently in the Russian-speaking community, they are talking about it more and more often.
Aleksey believes that this is probably due to the fact that in the Agile world, projects are launched that, without using DDD, will “slide into a sad state”, because there will be a discrepancy between the subject area and implementation.
First of all, Domain-Driven Design is a story about design, and the subject area is at the forefront in it. And the main emphasis in this approach is placed on interaction with business – with customers of software and applications.
To put it simply, it happens that for solving business problems, the “software production pipeline” is stretched, and ultimately, in the implementation of the solution of these problems, it may turn out to be completely different from what was originally intended. And here, in order not to play the “damaged phone”, DDD is used. Its goal is to reduce the distance between business and developers so that the latter understand as accurately as possible what kind of business processes they are implementing.
How to design a complex system from scratch?
A reasonable question was asked in the studio: “Let’s imagine that we have realized that we have a complex system that we will do using DDD and we even have a lot of time for that. Where should you start? ” Alexey gave some advice.
First, of course, you will have to start with MVP, that is, with “small pieces”, which will then “grow” into something bigger. The second is to understand the processes that need to be automated. At the same time, it is important to be in contact with those who set the tasks. For example, with products or with someone from business, top managers. The next step is to paint the scenarios in such a way that the context in which the given business processes exist is clear.
And by the way, many people use the Event storming system for these purposes – this is a way to bring developers and business experts together in one place in order to research the upcoming development together.
In Event storming, all interested persons gather and use stickers to build a sequence of events and those objects that generate these events on the board. It turns out a kind of visual map, in which it becomes clear how various entities interact and how they are combined in contexts.
Initially, the activity was carried out offline, but now this can be safely done online, for example, in Miro.
Event Sourcing (not to be confused with Event storming)
Event Sourcing is another hot topic today. This is an architectural pattern that is often mentioned in connection with DDD.
In fact, they are indirectly related, and there is no direct relationship between them – the fact is that Event Storming helps to generate events that can then be transferred to the Event Sourcing architecture. In general, the studio tried to figure out why they talk about Event Sourcing.
Recently in the community SpbDotNet there was a meetup where they talked about how one team applied Event Sourcing. They used it in an application that implemented auctions. There are bids, and they are, in fact, events that compete: it is important at what moment each of them happened, it is important to get the correct sequence from them in order to understand the final status of an aggregate, for example, a lot or an auction. And in this situation, Event Sourcing is fully justified.
But sometimes it happens that Event Sourcing is just unnecessary complication of the process. After all, it is easy to do it wrong and very difficult to do it right, because there are many places in it where you can “turn the wrong way.”
Event Sourcing is best used in competitive and immutable stories, says Alexey. The classic place for this pattern is financial transactions. There are financial events: credits or write-offs, and it is important for the developer that their sequence is, first of all, clear. Secondly, it could not be canceled – an unambiguous final balance is needed. And Event Sourcing makes it possible to do this so that the chain of events always goes only forward.
More details start at 45:15
CQRS – yay or nay?
The guys discussed that CQRS is rather a pattern used in the technical field. Is CQRS and DDD related?
DDD is more about side effects and changes, while CQRS is more about rendering. And this quality of it is just used in Event Sourcing, because in fact there is only a set of events, and, as a rule, you need to show data, states of objects. And in order to get this data, you need to make projections from events. In general, when you look at CQRS from this angle, you get a story about synchronous interaction from a UI / UX perspective.
A detailed discussion of this difficult issue – from 55:00.
Where and how to learn all this? (preferably before retirement)
Alexey advised to start with his report… He noted that “for this he told, to give an intro on the topic.”
In addition, it is worth reading books from the list of useful materials that will follow. The studio agreed that it was better to start reading something more general and easy to just understand the principles. And then you can move on to more complex and detailed books, for example, to Blue book Eric Evans.
You can also subscribe to the community DDDevotion and ask about everything that interests you. Subscribers can advise on a wide variety of topics – for example, how to use DDD in PHP, as well as in other stacks.
At the end of the conversation, Roma also asked an interesting question: “What problem should a developer face in order for him to understand that it’s time to delve into DDD?” In short, it is difficult to answer shortly 🙂 And they told in detail from 1:10:00.
Useful materials
-
Patterns, Principles, and Practices of Domain-Driven Design;
-
About CQRS / CQS and the return of the result by the command…
Previous episodes of the Dry the Oars podcast
-
Software architect: why is he needed and what is his curse;
-
Source of truth: how an analyst teaches a manager and a developer to work together;
-
CTO of All Startup QA for Beginners: How to Test a Rocket or Airplane;
-
Queue in the backend: what we stand for and where to start our journey;
-
Pandemic and IT business: how to adapt and what to do next.
