[alex-lawrence]

The idea of this book is to provide a practical guide on how to implement DDD, CQRS and Event Sourcing. I chose to use JavaScript and Node.js as alternative to Java or C#, which are often used in comparable literature. After reading it, one should understand the fundamental concepts, how to apply them and how they can work in code.

You can access a free sample of the book on the webpage in different formats.

I worked on the book for four years as a side project. In 2016, I had worked in three different projects that applied either some or all of the concepts. The last one was the main motivating factor for the book. It was a startup that was settled on DDD, CQRS and Event Sourcing, even though the developers had limited knowledge.

Together, we learned, experimented and applied as much as we could. We read "Domain-Driven Design" by Eric Evans, "Implementing Domain-Driven Design" by Vaughn Vernon and whatever we could find from Greg Young. With the knowledge we picked up and the experimentation we did, we felt in a good position. Still, there were many unanswered questions on how to put everything into code.

In 2016, before leaving the startup, I first thought about writing a book. Effectively, I wanted to create the guide the startup would have needed in the beginning. When I started, I was overly confident about my knowledge. However, throughout the years, I learned many details. Today, I know that I could not have written it in 2016 at once.

The final book is different from what I envisioned it to be at first. My initial goal was to write a short book with approximately 150 pages. The published version has now over 450 pages. However, I consider this a good thing. The book provides enough context to be read without any prior knowledge in DDD, CQRS or Event Sourcing.

I've written a blog post that covers my motivation on writing the book in even more detail: https://www.alex-lawrence.com/posts/why-i-wrote-a-book-on-dd...

I'd be happy to discuss your thoughts on and experiences with DDD, CQRS and Event Sourcing. Regardless whether it is about their combination, their sometimes counterproductive conflation or one of the concepts. Finally, if you have any input or feedback for me, it would be highly appreciated!

[aryehof]

Congratulations on the release!

My experience is that most supposed implementations of DDD are problematic because the focus is on the infrastructure, plumbing and implementation, rather than on the real challenge which is modeling a complex problem domain.

This is the exact opposite of Evan’s intention as stated in his book.

Because there is a general inability to model a complex system into an object model as is the basis of his book, focus falls onto programming constructs and things like “ubiquitous language” which pre-dates Evans and is self evident to most.

About 80% of CQRS/event sourcing projects I review or consult on are unsuccessful. In most cases this is primarily due to them being applied where they shouldn’t be, by (inexperienced) teams viewing these techniques as “silver bullets” to success.

I should note that I am mainly involved with line-of-business type systems, rather that projects focusing on computing infrastructure and the computing and data sciences, and therefore speak to the former.

[alex-lawrence]

Thanks!

It is important to note that my book is not an alternative to "Domain-Driven Design" by Eric Evans. Rather, it is an introduction to DDD, an explanation of CQRS and Event Sourcing and an implementation guide. Also, it is not explaining how to approach and model complex domain problems. I wouldn't consider myself experienced in that. Everything I worked with so far was rather trivial.

I can very much relate to your experience with projects that applied CQRS and Event Sourcing. In fact, the longest project I worked on was a negative example. The patterns were used as part of the system architecture. Their use was never justified with any reason specific to the domain or the business. In the end, some parts of the system would have been better off with a completely different architecture.

I already have convinced project teams to not use Event Sourcing when they thought they needed it. Also, I often hear it being conflated with Event-Driven Architecture.

[stepbeek]

I love this comment. I’ve definitely witnessed DDD terminology used as a lofty sounding justification for sexy tech, rather than a genuine attempt to model a complex domain.

I think that software developers too often underinvest in modeling a domain in favor of propping up an imagined silver bullet.

I wonder if there’s an easy way to hire for good behavior?

[victor106]

Thanks for sharing your experiences.

For CQRS, when you say “ it is due to them being applied where they shouldn’t be” can you provide more insighs?

In what cases do these architectures make sense and don’t ? What are the trade offs?

[AWebOfBrown]

This is interesting to me as someone who loves DDD but finds the tactical side hard to implement in Node.

A few questions stand out:

AFAICT implementing tactical DDD involves a lot of boilerplate code. That seems to be consistent with what you've written in your article on writing the book, mentioning "...we even built a Node.js framework as byproduct." If tackling DDD in Node requires so much work on something that isn't the businesses' core domain, and there's a lot of surface area for it to go wrong, why do it in Node?

As someone who writes predominantly TypeScript, static types feel like a much lower hanging fruit for alleviating some of the pain in tackling rich domains. As you've written the book in JavaScript, I'm curious whether you used plain JavaScript on the professional projects?

Also curious to hear from someone who has done tactical DDD in Java or C#: do you find a good supporting framework essential?

[alex-lawrence]

Could you explain which aspects specifically require a lot of boilerplate code? Judging from my experience, I think the tactical DDD patterns are straight forward to implement. I didn't mention this in my post, but the Node.js framework was only concerned with CQRS & Event Sourcing.

I fully agree with you that (static) types are inevitable for tackling rich/complex domains adequately. Personally, I would often recommend the use of TypeScript over plain JavaScript.

As for the book, when I started working on it, I was using plain JavaScript. Over the course of the past four years, there were times, when I considered to rewrite the DDD parts with TypeScript. My current plan is to add an appendix or integrate additional content about (static) typing.

While types are an important aspect for the Domain layer, I think the rest of the book works fine without TypeScript. Its absence might even help to keep the code example more concise.

> I'm curious whether you used plain JavaScript on the professional projects?

Yes, in both relevant projects we were using plain JavaScript (or CoffeeScript). We had many runtime type checks and a high test coverage to overcome the lack of static types. TypeScript would have definitely been the better choice.

[zappo2938]

What do you think of Nest.js and its CQRS implementation?

[alex-lawrence]

I only heard of Nest.js a few weeks ago and haven't had the chance to look it. Therefore, take my reply with a grain of salt.

Libraries and frameworks can help you with different things, but they can also get in your way. If the CQRS module of Nest.js seems useful for a specific scenario, I would give it a try.

CQRS can be implemented in many different ways. Even more, a lot of software is applying this pattern inherently to some extent.

If you separate a software (or a part of it) into a write side and a read side, the two become independent. They both only interact with the synchronization mechanism. Therefore, they are free to use their own set of patterns, libraries and even technologies. Many times, the two parts are operated as individual programs/services and can scale autonomously.

Personally, I never encountered a situation with implementing CQRS where I really would have needed a framework. In fact, I contributed to a Node.js framework for implementing CQRS and Event Sourcing. In hindsight, I think the framework was a mistake and should not even be used.

My book explains how to implement all the concepts, patterns and mechanisms without any third-party code. The goal is not to use the custom code in production, but to understand how everything works.

[ChicagoDave]

Can I get a printed copy?

[alex-lawrence]

Sorry, there is no printed version at this point. I wanted to focus on the e-book variant first.

While this is not necessarily an argument against a printed version, note that this book works best when reading on a computer. It comes with the full source code bundle and a small utility that allows to execute all code examples interactively.

Also, it is likely that there will be updates to the book in the near future. I'm already considering to write an appendix. By exclusively providing an e-book, iterative improvements are easier to do and the readers get all updates for free.

Nevertheless, I may consider to offer a printed version later on.