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'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!
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.
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?
I'm in the midst of an event driven microservice project. On our first try, we've created a distributed monolith.
That's why we decided to rewrite it in a more DDD driven way.
I've started reading the blue book, the red book and Scott Millett's "Patterns and Principles of DDD".
But the most helpful book I've found so far was "Domain-Driven Design in PHP", which I find a lot easier to grasp thanks to its hands on approach.
That said, as a Go/Javascript person I really appreciate another book on the topic. I appreciate the effort and I am going to buy it.
This is really the big problem with DDD microservices. Whilst I'm a huge fan of the two, my go to is to always start out with a monolith and enforce boundraries within the application that could potentially become microservices at somepoint in the future. Even go as far as to use an in-memory event-driven system in the monolith. Then and only then when the need arises do we pull it out into it's own microservice.
This has various benefits but the biggest one being you get to play with the design of the 'microservices' before actually committing to making them microservices allowing you to make better informed decisions. The harder part is that it does require stronger discipline and if not done correctly, a harder transition to microservices (e.g. pulling out the components)
In one project, where we could have done otherwise, we went consciously full Event Sourcing. In another project, the Domain Model was inherently event-based. In my book, the Sample Application first persists domain objects and is later refactored towards Event Sourcing.
While I read about the possibility of doing both at the same time, I never encountered this practice in a project. How I see it, there is always only one source of truth. If you apply Event Sourcing, it is the event log. Any other representation should be seen as derivation/projection.
The one long-term project where we applied Event Sourcing showed quite some challenges you can face with this pattern. For me, the most challenging aspect is the versioning of an event-sourced system. When the Domain Model evolves, it might necessitate changes to events or the introduction of new ones. Greg Young even wrote a book on this topic: https://leanpub.com/esversioning (I haven't read it though).
Just browsed the table of contents and was both happy and surprised to see an entire chapter dedicated to the UI.
How big is the sample application in the book? I've read a lot about DDD but things just don't seem to click for me, partly because example are trivial. For example, I read "Architecture Patterns with Python" (https://www.cosmicpython.com/book/preface.html) but just didn't find it practical. Some random thoughts I had while reading, in no particular order:
* what if domain logic can be optimized in the database?
* how do joins across multiple tables work?
* in Django I've come across plenty of examples where you have property method on a model that goes and performs additional queries. For instance, something along the lines of `my_post.get_latest_comment()`. Should this instead be somewhere in the service layer?
Thanks for the feedback. Happy to hear that you appreciate the UI chapter. For me, it was important to explain how to approach the User Interface. I often had the feeling that this part was a bit neglected when reading about CQRS & Event Sourcing.
The book contains numerous standalone examples throughout the chapters, which are all executable. At the end of each chapter, the explained concepts are applied to the Sample Application context.
The Sample Application is a greatly simplified task board. Users can register, login, create projects, manage team members and work with a task board. The task board is essentially a collection of items, grouped into three columns. Individual tasks contain details such as title, description, status, assignee, etc.
While there are some constraints/invariants in the Domain Model, I would consider the Sample Application fairly trivial. It does not represent a complex domain problem. One reason for this is that I personally did not encounter any highly complex domain so far. It would have been weird if I tried to explain something I am not really experienced in.
> what if domain logic can be optimized in the database?
IMHO, the question is a bit too generic. The generic recommendation would be to not put domain logic into the database. However, one would need to look at what the domain logic in question is. Also, what does "in the database" mean? Are we talking about code that is being executed in the database environment, such as PL/SQL?
> examples where you have property method on a model that goes and performs additional queries
This sounds a bit like the Active Record pattern or the use of an ORM, where one "model" is somehow linked to another. Again, a generic answer would be that domain objects should stay free of infrastructural concerns. If you have posts and comments and need to get the latest comment on a post, this represents a use case. Use cases are executed by an Application Service. This part is allowed to query any number of domain objects / data sources. If you would be using CQRS, you would likely have a denormalized Read Model that contains comments per post.
I have to say that my recommendations on JavaScript education resources might be pretty outdated. The book that helped me a lot with the JavaScript language (in 2010) was https://www.goodreads.com/book/show/2998152-javascript. However, this was before the ECMAScript standard and the Web APIs developed as fast as they are doing today. Node.js I learned exclusively from reading the documentation and experimenting with it.
Similar to what zeroc8 said, I heard that people liked "You don't know JS". Also, I agree with joshxyz that you can learn a lot from the MDN and the Node.js API docs. Especially MDN is a great resource for learning specific concept. As example, look at their Promises tutorial: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Furthermore, I also think the publications from Axel Rauschmayer are worth checking out (exploringjs.com).
The section in the Preface of my book might sound a bit daunting. Even if you don't know JavaScript, but have experience with at least one other programming language, that might be fine. I think the most challenging aspect is the asynchronous programming part, which is being used extensively due to Node.js.
For Javascript, I learned a ton from Frontend Masters. In particular for a deeper understanding of the language, Kyle Simpson's Deep Javascript Foundations where he connects the behavior of Javascript to the Standard. Overall, they have a number of high quality Javascript related courses.
Another architecture that seems to be becoming more common is having your CRUD functionality in a traditional monolith or a set of microservices, then writing events out or using change data capture to move that data into a data warehouse, where it is transformed for reporting purposes. While this is not the same as CQRS and event sourcing, it's a strategy that can be "bolted on" to your existing application and potentially capture some of the same benefits.
Yup, that's how it has worked at my past couple of jobs. One question that always comes up is what should be in a UI vs. what should be in a reporting dashboard owned by the data team?
That is a good question and, ideally, I should be able to answer it. Unfortunately, I don't know. The book started as a passion project and I never analysed the market in any useful way. However, I think that there is a certain potential for extending the existing market by making people interested in the topics.
This comment breaks both the HN guidelines and the Show HN guidelines. Please don't do that. We're trying to have a culture in which people who share their work get substantive feedback and discussion. Cheap dismissals undermine that badly—and since they're the internet default, we need to be conscious about this.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
In fact, the book was called "Implementing DDD, CQRS and Event Sourcing in Node.js" up until the release of its complete version. I thought about this for a longer time and decided to remove the "in Node.js" part from the title. Instead, I made it clear in the book description. In my opinion, the book can be valuable for anyone who is interested in the concepts, regardless of technology choices.
I think that it is fair to say that my book is partially also about Node.js, but not primarily. I wouldn't say though it is about JS. In fact, many of the code examples would look similar in other languages. Furthermore, the use of Node.js helps to provide concise code examples and executable code without much ceremony.
When reading "Implementing Domain-Driven Design" by Vaughn Vernon, all the code examples are in Java. The book "Enterprise Integration Patterns" has a lot of code examples and all of them are also in Java. The most recent edition of "Refactoring" by Martin Fowler uses JavaScript. Still, I wouldn't say that these books are about a particular programming language.
alex-lawrence|5 years ago
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|5 years ago
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.
AWebOfBrown|5 years ago
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?
zappo2938|5 years ago
ChicagoDave|5 years ago
zeroc8|5 years ago
That said, as a Go/Javascript person I really appreciate another book on the topic. I appreciate the effort and I am going to buy it.
harrylucas|5 years ago
This has various benefits but the biggest one being you get to play with the design of the 'microservices' before actually committing to making them microservices allowing you to make better informed decisions. The harder part is that it does require stronger discipline and if not done correctly, a harder transition to microservices (e.g. pulling out the components)
notretarded|5 years ago
JCDenton2052|5 years ago
alex-lawrence|5 years ago
While I read about the possibility of doing both at the same time, I never encountered this practice in a project. How I see it, there is always only one source of truth. If you apply Event Sourcing, it is the event log. Any other representation should be seen as derivation/projection.
The one long-term project where we applied Event Sourcing showed quite some challenges you can face with this pattern. For me, the most challenging aspect is the versioning of an event-sourced system. When the Domain Model evolves, it might necessitate changes to events or the introduction of new ones. Greg Young even wrote a book on this topic: https://leanpub.com/esversioning (I haven't read it though).
yeswecatan|5 years ago
How big is the sample application in the book? I've read a lot about DDD but things just don't seem to click for me, partly because example are trivial. For example, I read "Architecture Patterns with Python" (https://www.cosmicpython.com/book/preface.html) but just didn't find it practical. Some random thoughts I had while reading, in no particular order:
* what if domain logic can be optimized in the database?
* how do joins across multiple tables work?
* in Django I've come across plenty of examples where you have property method on a model that goes and performs additional queries. For instance, something along the lines of `my_post.get_latest_comment()`. Should this instead be somewhere in the service layer?
alex-lawrence|5 years ago
The book contains numerous standalone examples throughout the chapters, which are all executable. At the end of each chapter, the explained concepts are applied to the Sample Application context.
The Sample Application is a greatly simplified task board. Users can register, login, create projects, manage team members and work with a task board. The task board is essentially a collection of items, grouped into three columns. Individual tasks contain details such as title, description, status, assignee, etc.
While there are some constraints/invariants in the Domain Model, I would consider the Sample Application fairly trivial. It does not represent a complex domain problem. One reason for this is that I personally did not encounter any highly complex domain so far. It would have been weird if I tried to explain something I am not really experienced in.
> what if domain logic can be optimized in the database?
IMHO, the question is a bit too generic. The generic recommendation would be to not put domain logic into the database. However, one would need to look at what the domain logic in question is. Also, what does "in the database" mean? Are we talking about code that is being executed in the database environment, such as PL/SQL?
> examples where you have property method on a model that goes and performs additional queries
This sounds a bit like the Active Record pattern or the use of an ORM, where one "model" is somehow linked to another. Again, a generic answer would be that domain objects should stay free of infrastructural concerns. If you have posts and comments and need to get the latest comment on a post, this represents a use case. Use cases are executed by an Application Service. This part is allowed to query any number of domain objects / data sources. If you would be using CQRS, you would likely have a denormalized Read Model that contains comments per post.
Raz2|5 years ago
heybrendan|5 years ago
> Working through the book requires advanced knowledge in JavaScript and in Node.js.
Do you have any recommendations on various Javascript / Node.js education or training resources that would make good precursors to your book?
Furthermore, any general advice for the uninitiated?
alex-lawrence|5 years ago
Similar to what zeroc8 said, I heard that people liked "You don't know JS". Also, I agree with joshxyz that you can learn a lot from the MDN and the Node.js API docs. Especially MDN is a great resource for learning specific concept. As example, look at their Promises tutorial: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Furthermore, I also think the publications from Axel Rauschmayer are worth checking out (exploringjs.com).
The section in the Preface of my book might sound a bit daunting. Even if you don't know JavaScript, but have experience with at least one other programming language, that might be fine. I think the most challenging aspect is the asynchronous programming part, which is being used extensively due to Node.js.
colmvp|5 years ago
joshxyz|5 years ago
- nodejs.org api docs for nodejs stuff
- exploringjs.com for ES spec differences and progression
- caniuse.com for checking browser support
- there are bundlers like webpack and transpilers like babeljs but those are a little beyond the basics
zeroc8|5 years ago
aethr|5 years ago
https://javascript.info/
satyrnein|5 years ago
yeswecatan|5 years ago
maxekman|5 years ago
I’m the author of Event Horizon, a ES/CQRS toolkit for Golang: https://github.com/looplab/eventhorizon
alex-lawrence|5 years ago
maxthegeek1|5 years ago
unknown|5 years ago
[deleted]
unknown|5 years ago
[deleted]
stevenalowe|5 years ago
alex-lawrence|5 years ago
blackrock|5 years ago
alex-lawrence|5 years ago
02020202|5 years ago
[deleted]
hurril|5 years ago
[deleted]
dang|5 years ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/showhn.html
alex-lawrence|5 years ago
I think that it is fair to say that my book is partially also about Node.js, but not primarily. I wouldn't say though it is about JS. In fact, many of the code examples would look similar in other languages. Furthermore, the use of Node.js helps to provide concise code examples and executable code without much ceremony.
When reading "Implementing Domain-Driven Design" by Vaughn Vernon, all the code examples are in Java. The book "Enterprise Integration Patterns" has a lot of code examples and all of them are also in Java. The most recent edition of "Refactoring" by Martin Fowler uses JavaScript. Still, I wouldn't say that these books are about a particular programming language.
notretarded|5 years ago
>Then I see JavaScript and Node.js
What's wrong with this? The underlying architectural patterns and abstractions you should be able to pick out and apply to your technology of choice.