Running with Ruby

Tag: Rails (page 2 of 60)

Domain-Driven Rails – Mediocrity-Driven Book


  • This is a review of the Domain-Driver book and its content only. Keep in mind, that this book can be bought also with code, exercises and workshops. Those weren’t the subject of this review.
  • This is a review of the beta version of the book. Arkency didn’t mention that on their site, but this has already been fixed. I highly recommend checking their website for updates and/or fixes, as not all the points from this review might still be valid.
  • The author was kind enough to comment this review, so please go to the comments section for his perspective.


It’s been a while since my last technical book review. I’ve decided to have a go at Domain-Driven Rails as this subject is one of the things that I’ve been particularly interested in for quite a while now.

For those who don’t know me, I’m the creator of Karafka framework, a tool that can and is used for simplifying Apache Kafka based Ruby applications development. It is used by multiple teams for implementing the Domain-Driven approach (mainly, for the Domain events / Event sourcing parts of DDD)  within their Ruby and Rails applications.

I’ve been using the DDD approach for both: new and existing systems for over 3 years and I can definitely say, that if you want to build complex systems, which can be maintained and developed, this is the way to go.

But is Domain-Driven Rails the best book to read before tossing yourself into deep end? Unfortunately, I’m not quite sure.

Aim of this review

The aim of this review is to help you decide whether or not this book is a good choice for you and is it worth spending $49 or more.

Who is the book target reader?

I would say, that this book is definitely not for the readers who:

  • just finished some Ruby on Rails tutorials,
  • recently mastered basics of CRUD and scaffolding,
  • didn’t encounter any of the problems that this book aims to solve,
  • your biggest applications contain +/-20 models at most and have only simple business logic,
  • you’ve never used Sidekiq or any other background processing tools.

Of course it doesn’t mean that it won’t be useful for you at all. It’s more about giving the problems and challenges described in this title a deeper, personalized context without which it will be just a next theoretical (from the usage perspective) position in your library.

It’s also not a glossary type of book, which you can open, find a solution and close it again. DDD is a huge subject and cherry-picking of some parts as remedies may not be the best idea.

DD Rails can be a good choice if:

  • you’ve spent 2+ years with Rails built systems,
  • you just need a really quick introduction into the subject, without theoretical base or anything else,
  • you’ve just started a new job in a company where they use DDD and you want to get a grasp of it but don’t have too much time.

In such cases, go for it, but before you do, please read the rest of the review.

Advanced programmer reviewing book for mids? Does it even make sense?

You might say, that I’m not the best guy to review this book. You might say, that I’ve been using the approach and solutions presented in it for a long time, so my expectations may not exactly be met by this book. And I think just the opposite, because I remember myself reading Implementing Domain-Driven Design and trying to adapt knowledge found there into the systems built with Ruby and Rails. I remember times, when there were no decent libraries nor articles for Ruby programmers on that matter. Heck, that was one of the reasons Karafka was born!

The review

Below I present some of the things that I liked/disliked in particular. If you are interested in a TL;DR version, please go to the summary section.

What did I like about this book

Undoubtedly, there are some good aspects of this book. Here are a few that I appreciated the most.

The idea

I’m a big evangelist of DDD and its components. I really appreciate the time and the effort Robert & the Arkency team invested to make DDD more accessible and easier for Ruby and Rails developers.


If you strive for more information on a given matter, at the end of each chapter you will find tons of references and links for further exploration.


Sagas are one of the things I find hard to explain to people*. We are accustomed too much to the HTTP way of thinking.

Sagas are meant to be asynchronous and they need to be designed that way.

Because saga will be asynchronously processing domain events from many bounded contexts, which can happen at any time, there is potential for race conditions

Luckily the guys behind this publication didn’t forget about it. They embrace it and present a few ways of dealing with this kind of situations.

They also cover the at-least-once delivery case, idempotent sagas and events duplication:

If the message queue that you use gives at-least-once delivery guarantees your sagas should be idempotent and handle duplicated events.

Too bad though, that they didn’t mention the exactly-once Kafka’s feature.

* Especially when you don’t call them process managers

Code examples and business context

The book is rich with examples. Many of them are from finance-related systems that Arkency develops and maintains, which adds an extra value to it. Most of them are clear and stripped out of useless parts that aren’t relevant to the discussed subject.

Things I didn’t like about that book

The good part is behind us. Now it’s time for things that in my opinion made this book much worse that it could be.

Rails or Ruby, Ruby or Rails?

The first page of the prologue and already a funny contradiction:

One topic that was relevant here is how to grow as a Rails developer.

and a few sentences later we get this:

If you focus too much on the technology dimension,
you will become too reliant on “The Framework Way”

Shouldn’t this approach be applied to writing books as well? If so, then maybe the book should be called DD for Ruby. I’m not saying, that this book is tightly bound to the Rails framework, but it would be good not to become too reliant on “The Framework Tooling”. If you get knowledge from a framework perspective*, it will always be distorted. More or less, but it will be and you need to remember this while reading the book.

* This applies as well for a programming language layer

Read a book to understand a book

As I’ve mentioned, there is almost no pure theoretical knowledge presented in DDR. This is an advantage and disadvantage at the same time. I couldn’t help feeling like something was missing and that I could understand everything because I already understood the matter. It means, that if you’re new to the subject, you might find yourself googling for not yet explained acronyms or terminology that

we will discuss in a moment.

The lack of glossary at the end is also a bummer. Especially since (as mentioned), there are times when the explanation for a term is not during its first  occurrence.

Oversize images?

I’ve counted a number of pages where there would be less than 50% of text and/or some oversize images. There are 23 pages like that. It means, that more than 12% of the book is useless.

Note: this point might no longer be valid. Please visit the Updates section of this review.

It took me 1 day to read it. For me, +/- 120 pages of content is not enough to call it a book.

A limited perspective of DDD the Arkency way

If you decide to buy this book and use concepts and code snippets presented there, keep in mind, that you might become Arkency-dependent.

They present their libraries, their approach and their solutions. There would not be anything bad about that, if they explored other solutions and tools available.

They also seem to be really agnostic about their technological stack. They recommend using same database for storing events:

(…) I strongly recommend at the beginning of your journey into the world of asynchronicity, eventual consistency and async handlers: a message bus with a queue in the same SQL database that you for your app. It really simplifies error handling on many levels.

But what they forgot to mention is that:

  • You might not be able to deserialize YAML events in other technologies that easily.
  • You cut yourself from a set of flexible tools that will allow you to easily expand and replace Ruby based components with those written with Go, Elixir or any other technology you find suitable for doing certain jobs.
  • You might become narrow-minded about potential solutions and tools you can add to your stack (because they will have to play along with the Arkency gems).
  • Going for an all-in-one DB solution, tightly integrating all aspects of your software with it, makes it much harder to replace a message bus like that with a more generic one.

Note: I wouldn’t mind that at all, if the books description stated, that most of the examples and code snippets are related to their gems and libraries.

Outdated before published

Long time ago, when Rails weren’t that stable in terms of concepts and internal API, I used to say, that a released book about Ruby on Rails is already an outdated book. This sentence was true especially for printed versions that could not be easily updated.

But I’ve never seen a book that would use abandoned and outdated gems. I was quite surprised to notice, that there are almost 2 pages about Virtus, a library that was abandoned by its creator Solnic (great explanation on the reasons can be found here). Everyone that used to use it, knew from 2015, that it’s going to be totally dropped in favor of the dry-rb ecosystem. But hey, probably authors explore those in the book as well. But did they?

I am not super familiar with the dry-rb ecosystem but I am pretty sure that dry-types, dry-struct and dry-validations provide a nice experience in building command objects as well.

Published but incomplete

Let the image speak for itself:

I know, that the Lean approach is getting more and more popular, but should it be applied to books? I don’t think so. 

Note: This has already been explained in the Updates section and in the comments section of this review.

Eventide as a bonus

When I buy a programming book, I expect it to be written by people that deal with the subject on a daily basis. What did I get as a bonus in DD Rails? 11 page long description of Robert’s first Eventide encounter. Really? I don’t mind him playing with that set of libraries. I would even appreciate his point of  view on them in a blog post, but spending 11 pages out of a book just to describe his first impressions on it?

Summary / TL;DR

Note: Please read the Updates section as not all of this TL;DR might be up to date.

Believe me, I’m not happy to say it, but I must. This book is mediocre at best. Its content could fit into 10-15 blog posts. Then I would say, that it is a really good starting point for people not familiar with DDD. But to sell it as a book?

I’m disappointed with what I’ve read. I know, that Arkency can do way better. I know, that they have 100% guarantee policy but even then, it doesn’t justify selling a product that is:

  • incomplete (refers to the beta version, please read the Updates section),
  • outdated,
  • without proofreading,
  • too short,
  • badly structured in terms of layout,
  • presenting only a single set of libraries and a single perspective on the subject.

There’s a huge difference between expectations against blog posts and books and I think, sometimes it’s worth reminding some people about it.

Sharing models between Rails apps – Keeping Rails engine migrations in the engine

Note 1: If you have an option to use micro services and/or event-sourcing, go for it! Rails solutions based on shared models and a single shared database, can bring you in a longer perspective more harm than good.

Note 2: This approach is great when your data is tightly coupled and you can’t easily switch from a single app to a distributed model.

Sharing models between Rails apps – basics

The concept of shared models is really well described by Fabio Akita in following articles:

However, his approach towards migrations comes from his really specific use-case (two DBs in a single app – one shared and one private).

Managing migrations – standard Rails engine approach

Standard Rails engine approach assumes that your migrations will be copied from the engine into the application when you run following command:

bundle exec rake engine_name_engine:install:migrations

This is great when:

  • You have a single “master” application that you want to decompose with engines
  • you have multiple applications with separate databases and you want to use business logic from the engine from each of them
  • If you want to to have a single “master” application that is supposed to run all the migrations from the engine

However with some benefits, you get a huge (in my case) drawback – when you copy migrations, their timestamp is being changed. It means that if you share same database across multiple applications that also share the same engine, you will end up with a single migration being executed (assuming you install the migrations) from each of the separate applications.

Single database and no master application

This won’t do if your case is similar to mine, that is:

  • Single database
  • Multiple applications that need to share same models and scopes
  • Migrations should be executed in the first application that is being deployed after the model engine change (not from the “master” app)
  • There should not be any patching / adding  code into any of the apps that will use shared models gem

Keeping your migrations inside your model engine

Solution for such a case (in which all the models are being kept inside the gem) is pretty simple: you just need to append migrations into your apps migrations path without:

  • Copying them from the model engine gem
  • Changing the timestamp
  • Executing the same migrations multiple times

To achieve such a behavior, we will take advantage of how Rails config paths, migrations and initializers work:

  • Config paths aren’t bound to the Rails.root directory (which means that they can use files from gems and other locations)
  • Config paths are appendable (which means we can add our gem migrations into the app migration list without changing timestamps and copying files)
  • Engine initializer allow us to bind this process from the model gem, keeping the apps untouched (they will think that those migrations are theirs)
  • Rails migrations execution details are stored in schema_migrations table, so unless executed exactly the same moment (so transactions overlap) a single gem migration will not be executed twice

All of this comes down few lines of Ruby inside Rails engine engine class (engine_path/lib/engine_name/engine.rb):

initializer :append_migrations do |app|
  # This prevents migrations from being loaded twice from the inside of the
  # gem itself (dummy test app)
  if app.root.to_s !~ /#{root}/
    config.paths['db/migrate'].expanded.each do |migration_path|
      app.config.paths['db/migrate'] << migration_path

TL;DR – Final solution


module ModelEngine
  class Engine < ::Rails::Engine
    initializer :append_migrations do |app|
      # This prevents migrations from being loaded twice from the inside of the
      # gem itself (dummy test app)
      if app.root.to_s !~ /#{root}/
        config.paths['db/migrate'].expanded.each do |migration_path|
          app.config.paths['db/migrate'] << migration_path


Most of the time sharing models is bad, but there are some cases app data is really tightly coupled together and exposing API with building microservices around it would mean a huge overhead. For such cases model gem with internal migrations might be a great solution.

Warning: If you decide to go that road, please make sure, that:

  • Your models are stable
  • Your models are slim and without any business logic
  • Your models don’t have any callbacks or external dependencies
  • If your models have external dependencies, make them model gem dependencies
  • Your models are loosely coupled (if you follow Akitas approach with concerns it won’t be hard)
  • Your applications are well tested
  • Your model gem is well tested
  • You don’t use model validations – instead you can use Reform, Dry-Validations or any other solution that allows you to move validations logic out of models
  • All the model related things and migrations are inside the model gem
  • Migrations from external gems like Devise or FriendlyId are also inside the gem

With all of this in mind, you should be fine :-)

Cover photo by: Unsplash on Creative Commons 0 license.

Olderposts Newerposts

Copyright © 2019 Running with Ruby

Theme by Anders NorenUp ↑