Valeria Kokina from Daxx talks to Gregory Young, one of creators of CQRS, an independent consultant and serial entrepreneur, a well-known trainer on DDD/CQRS/ES and frequent speaker at international conferences, about the essence of DDD/CQRS/ES, when it worth using it and how to get started with DDD/CQRS/ES, about Ukrainian developers and his seminars in Ukraine.
Valeria Kokina: Greg, could you tell our readers about yourself and your experience with Domain Driven Design (DDD), Command and Query Responsibility Segregation (CQRS), and Event Sourcing (ES)? How did you start using DDD/CQRS/ES?
Gregory Young: For Domain Driven Design many years (even before the book «The Blue Book» was published!). Much of the knowledge in Domain Driven Design is Object Orientation done right. When I first saw the book it was a reinforcement of many of the practices I was already accustomed to and much of it "just felt right", at the same time it provided a vocabulary and formalization of many concepts. For CQRS, it is a common pattern that we have seen throughout the history of distributed systems that previously just had no name. ES as well is an age old pattern, in research I have traced it back to sumeria! My first experiences with it were actually in university.
Valeria: What is CQRS in practical terms?
Gregory: I get this question very often. Many people associate CQRS to messaging based systems and event sourcing and equate it to complexity. CQRS however is a very simple pattern recognizing that reads and writes should be treated differently in most systems.
Valeria: Which projects are the best to start doing CQRS?
Gregory: As CQRS tends to be used exclusively in behavioural systems the real question boils down to when is it worth my effort to build a behavioural system as opposed to a CRUD based system. Behavioural systems by definition require a larger investment into analysis. Figuring out whether the analysis is worthwhile can often be a tricky question that I could easily write ten pages about.
Its also important to remember that when people discuss CQRS it needs to be put in the context of a component (or service) level decision. An overriding architecture would be more something like SOA+EDA. Many decisions will be made in different components and CQRS or even Event Sourcing may fit into some but not others. In other words, CQRS is not a top level architecture.
In terms of figuring out within a component whether a behavioural viewpoint may be better suited I often look at two things. The first is the amount of complexity within that component. Is it just basic validation ending into a database or is there a lot of rich logic? The second is a better match.
The second thing I look at is how much competitive advantage comes from this particular component for our organization? Is this something that is within our core business or is this something outside our core business? If its in our core business it will often pay back many fold to spend the additional time in terms of analysis.
Valeria: What tech stack would you recommend for CQRS implementation?
Gregory: CQRS is fairly tech agnostic. A stack is the least important thing. That said there are some stacks that don't fit well with it. Many stacks rightly have a heavy focus on CRUD (Create,Read,Update,Delete). CQRS, DDD, and ES are all about behavioural systems. If you are in a stack that is opinionated and geared towards CRUD (I'm looking at you Ruby on Rails) it may not be a natural fit as you will be fighting your stack.
Valeria: What examples can you give me about how CQRS helps you in yours work? Are there any examples of companies which have already used CQRS and done this successfully?
Gregory: There are tons of companies that have applied CQRS (and Event Sourcing) many without knowing the names of the patterns. If you look inside of nearly any distributed system you will start to see the patterns.
Valeria: I know that you have already been to Ukraine and spoken to Ukrainian IT Community. How proficient are Ukrainian developers in CQRS? What can you say about Ukrainian developers?
Gregory: Ukraine has a great community. In fact when I was setting up the development team for the Event Store (geteventstore.com - a functional database) I intended from the beginning to hire the team in Ukraine. At present the team is colocated in Lviv. That project is one with the highest levels of engineering expertise required.
I really hope that one day the rest of Europe and the world will look towards Eastern Europe as a whole for the high quality of engineers available and not as being a lower cost.
Valeria: What is the best way to plunge into CQRS? Are there any websites, books you can recommend to our readers?
Gregory: Rinat Abdullin has put together a nice page collecting links as well as some of his own works. People can also check out dddcqrs.com which contains about 7 hours of video as well as many pages of material.
Valeria: I’ve heard that you were working under your book dedicated to CQRS. Can you tell me more about this?
Gregory: At this point I am more focused on getting about 20-25 hours of professionally done video delivered. I will then be focusing back on writing in all of my "free time" :) though there are over 100 pages of material I have written on dddcqrs.com in the docs section for free download.
Valeria: On the 24th-26th of June you are giving your three-day DDD/CQRS/Event Sourcing class in Kiev. Could you tell us about the seminar? How to take part in it?
Gregory: The seminar is free (by donation). It unfortunately sold out in about 16 hours. It is possible however that another such seminar could be arranged in the future.
Valeria: Could you tell me more about seminars you are giving? Do all your classes free to attend? Where can we find the information about the coming seminars?
Gregory: Most my classes are not free to attend. This year I wanted to spend some time teaching the class to people that would ordinarily not be able to attend. At this point we are also trying to setup a class in Kharkiv either over the summer or in the fall that would work much like the one in Kiev. Of course if I did that then my guess is I would also likely need to do one the next time I am in Lviv.
Valeria: Gregory, thank you very much for your time and answers.