What do you think?
Rate this book
Domain-Driven Rails
- GenresSoftware
170 pages, ebook
Published August 18, 2017
1 person is currently reading
28 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
February 8, 2018
Some good explanations in the beginning about Bounded Contexts, but the main focus of the book are events, commands and related stuff. There are (very) brief explanations about domain modeling patterns, such as Entities, VOs and Aggregates and that's it.
Code samples are valuable, although repetitive.
When it comes to editing - as mentioned by other reviewers - the book is poorly written / revised, there's no conclusion (it seems like a bunch of rushed blog posts). The author should have spent more time to make it more professional.
Code samples are valuable, although repetitive.
When it comes to editing - as mentioned by other reviewers - the book is poorly written / revised, there's no conclusion (it seems like a bunch of rushed blog posts). The author should have spent more time to make it more professional.
October 14, 2017
Excellent content, but delivered in a poor way. In the most expensive package, the book costs $99 but it still contains typos, quite a lot of code snippets are not colored, which seems as if no one cared to check if the book was generated properly in the end. Not to mention that 1/6th of the book is copy&paste from Arkency blog posts. It looks really bad and seems as if the author just wanted to put something extra inside so that the book appears bigger to justify its price. For such a high price all those things are unacceptable.
Nevertheless, I would highly recommend reading it - the book presents some great ideas that might really help in complex Rails apps and I'll most likely take advantage of those ideas soon. If it weren't for all those issues, I would gladly give 5-star rating
Nevertheless, I would highly recommend reading it - the book presents some great ideas that might really help in complex Rails apps and I'll most likely take advantage of those ideas soon. If it weren't for all those issues, I would gladly give 5-star rating
August 31, 2017
There are some good ideas here, but the book badly needs an editor and the help of a technical writer, perhaps. The writing style buries the point amongst heavy code examples and it's hard to follow at times.
Some chapters feel like they were blog posts that were just added to the book.
Some chapters feel like they were blog posts that were just added to the book.
September 26, 2017
Interesting ideas, but it just seems like a collection of blog posts with poor editing.
October 15, 2022
It describes nice ideas. From the drawbacks though - it is not very well edited, many spelling errors. Also quite a lot of repetition of content.
February 3, 2022
We're reading this book as part of a book club at work. I read an early copy that still needed a lot of editing to fix typos and grammar. I'll admit that I found the defective writing very distracting.
The beginning covers concepts of Domain-Driven Design like bounded contexts, value objects, and aggregates. I like how the author uses services to implement behavior that does not squarely belong to any single aggregate. It all sets the stage for the latter part where the author shows how to use events to normalize communication between aggregates. It is also a good way to enforce partitions between parts of the code.
The examples are all set in the context of Rails and rely heavily on the rails_event_store gem and the patterns it promotes. These are useful, but they are also difficult to replicate with other messaging systems like RabbitMQ or Kafka. For example, with rails_event_store, you can put a message on multiple streams very cheaply, so you can have per-object streams (e.g., user-1234) sitting next to general streams (e.g., users). This allows you to rehydrate User with ID 1234 by replaying that stream whenever needed. RabbitMQ won't let you replay streams and Kafka streams are more costly to replay from the beginning, so you tend to maintain state in memory for the lifetime of the process.
When the author started discussing process managers, they looked to me a lot like the saga pattern with an orchestrator. The author does point to how both process manager and saga have subtly different definitions between the CQRS and Microsoft communities. Apparently, process manager comes from Enterprise Integration Patterns .
The author covers many of the problems I've seen before when timing events and messages with database transactions, dealing with failures and rollbacks, and trying to guarantee once-and-only-once semantics. The author describes a nice setup where an internal event system (e.g., rails_event_store) is tied to database transactions, which feeds a separate process that puts them on the external message bus (e.g., Kafka). If a transaction rolls back, the events are removed from the internal bus before they were visible to others and it is as if nothing had happened. Once the transaction commits and the event is persisted, it gets published to the rest of the system.
I also really appreciated how the author used Ruby's #permutation and #repeated_permutation methods to programmatically test variations of a sequence of messages in situations where the order doesn't matter.
The author references Stephan Hagemann's Component-Based Rails Applications in a few places.
The beginning covers concepts of Domain-Driven Design like bounded contexts, value objects, and aggregates. I like how the author uses services to implement behavior that does not squarely belong to any single aggregate. It all sets the stage for the latter part where the author shows how to use events to normalize communication between aggregates. It is also a good way to enforce partitions between parts of the code.
The examples are all set in the context of Rails and rely heavily on the rails_event_store gem and the patterns it promotes. These are useful, but they are also difficult to replicate with other messaging systems like RabbitMQ or Kafka. For example, with rails_event_store, you can put a message on multiple streams very cheaply, so you can have per-object streams (e.g., user-1234) sitting next to general streams (e.g., users). This allows you to rehydrate User with ID 1234 by replaying that stream whenever needed. RabbitMQ won't let you replay streams and Kafka streams are more costly to replay from the beginning, so you tend to maintain state in memory for the lifetime of the process.
When the author started discussing process managers, they looked to me a lot like the saga pattern with an orchestrator. The author does point to how both process manager and saga have subtly different definitions between the CQRS and Microsoft communities. Apparently, process manager comes from Enterprise Integration Patterns .
The author covers many of the problems I've seen before when timing events and messages with database transactions, dealing with failures and rollbacks, and trying to guarantee once-and-only-once semantics. The author describes a nice setup where an internal event system (e.g., rails_event_store) is tied to database transactions, which feeds a separate process that puts them on the external message bus (e.g., Kafka). If a transaction rolls back, the events are removed from the internal bus before they were visible to others and it is as if nothing had happened. Once the transaction commits and the event is persisted, it gets published to the rest of the system.
I also really appreciated how the author used Ruby's #permutation and #repeated_permutation methods to programmatically test variations of a sequence of messages in situations where the order doesn't matter.
The author references Stephan Hagemann's Component-Based Rails Applications in a few places.
Displaying 1 - 6 of 6 reviews