As a Ruby on Rails community, we have been immune to the changes in the programming world around us for a long time. As if nothing new has been introduced since the beginning of times (or the release of the first version of RoR in 2005). Whereas important and interesting innovations occur all around.
In 2003, Eric Evans released a book titled "Domain-Driven Design: Tackling Complexity in the Heart of Software" which has changed the landscape of many programming technologies. The ideas and techniques promoted by this book are well known among Java, C# or PHP programmers. The approach is used to build better and more reliable software. Especially at the enterprise level, where the attention to detail is at its peak.
Eric Evans wasn't the only person responsible for the global DDD boom. His initial book is often referred to as "The Blue Book", but there is also "The Red Book" or in fact "Implementing Domain-Driven Design" by Vaughn Vernon. These two figures, alongside others who grew out of the Smalltalk community, have driven the programming world into the realm of DDD.
What is Domain-Driven Design?
There are two layers in which it can be described:
Strategic DDD explains how to prepare and maintain a project. Its goal is to characterize parts of the system as Bounded Contexts, refine the terminology using Ubiquitous Language and illustrate the relationships using Context Maps. It is about gathering business expectations and needs. It shows how important it is to communicate doubts and questions back to the management. Finally, it is about IT working hand-in-hand with business to achieve a common goal.
Tactical DDD is a set of techniques used to construct a precise, coherent and useful model of the domain. It defines a set of building blocks such as Entities, Value Objects or Aggregates. It describes how to use Repositories and Factories to maintain the design and its implementation clean and well-defined.
Can DDD be used with Ruby on Rails?
On the strategic level, you don't think about a framework or a programming language. Doman-Driven Design helps you to focus on the correct context. It teaches what kind of vocabulary to use and how to approach the architectural decisions.
On the tactical level, Domain-Driven shows that RoR doesn't have to be all about procedural services, quickly becoming god objects. It teaches how to describe your domain in a thought-out and flexible manner. It guides towards decoupled modules and consistent data.
How to start with DDD in Ruby on Rails
There is no one-way. I can only share mine. One thing you SHOULD NOT do at first is jumping right into The Blue Book. It may be too complicated without some initial preparation.
I've started by absorbing materials from various conferences and talks. I've been listening to DDD meetups and related podcasts. I've used recorded talks and high-level articles. When I felt ready, I ordered books by Evans and Vernon and started reading. What came to me as quite a shock was that I really got into them. I was so eager to know more that for the first time it didn't feel like reading "yet another programming book". It was like discovering a new world.
You have to find your own way. But believe me - it's worth it!
At first, it may be hard to incorporate DDD theory into such a conservative framework as Ruby on Rails. Luckily, you will find many examples in the upcoming blog posts within this series. You will also learn how to incorporate them into your projects.
Future articles will cover the mentioned concepts in detail. The first one, about value objects, will be published in just a few days. There will be others, describing tactical and strategic elements of Domain-Driven Design.
Come back from time to time to read a new chapter.
- Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
- Vaughn Vernon, Implementing Domain-Driven Design
- Eric Evans, What is DDD - DDD Europe 2019
- Paul Rayner, DDD By Example - DDD Europe 2020