BT

Your opinion matters! Please fill in the InfoQ Survey!

Introducing DDD in a Project at “Which?”

| by Jan Stenberg Follow 9 Followers on Aug 16, 2015. Estimated reading time: 2 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

The team at "Which?", the brand name for the UK Consumers' Association that provides unbiased reviews of consumer goods, began a project to overhaul their Ruby on Rails based main website. After two proof of concepts failed, the business decided to take a more agile and incremental approach and in a restart of the project inspired by Domain-Driven Design (DDD) having developers talk with domain experts. Chris Patuzzo, technical lead at Which, described the experience in a recent talk for Skillsmatter.

Patuzzo describes DDD as being about capturing the concepts of the business and building software around that understanding. In the project restart developers began talking to domain experts trying to understand what the business actually does in order to come up with suitable models and finding the boundaries within the system. In Patuzzo’s experience it’s much easier to work on systems with clear boundaries. By keeping concerns separately the system is easier to understand and if a need later arises to extract parts of it this will be simplified.

DDD suggests breaking a problem into layers, each with its own responsibility, e.g. presentation, domain and infrastructure layer. Patuzzo notes that a common practice when using Rails is to combine the domain and infrastructure layers, thus breaking the DDD suggestion. An alternative to layers is the Hexagonal architecture described by Alistair Cockburn but Patuzzo is not a strong advocate of this style as he believes it can be confusing. He notes that it’s helpful in managing complexity and keeping a focus on the core domain but also that the ideas are new for the Ruby community needing some time to get used to.

One measure of complexity is the number of interactions between objects. Aggregates and aggregate roots minimize this by only allowing interaction within an aggregate and between the roots. Patuzzo calls this the surface area of the system. In a Ruby world using active records all classes are global constants accessible from everywhere in a system but the developers circumvented this by prefixing class names with the name of the aggregate. Breaking things up into aggregates giving more structure to the communication was a learning curve which caused the most friction during the work but in retrospective Patuzzo is quite happy with the result.

In summary Patuzzo notes that although it so far has been a taxing experience the developers have learnt the basic patterns and ideas from DDD, how to break an architecture into layers and separation of concerns and how to build a system that anticipate change. By building on top of a model that represents the business he believes they can now better satisfy new requirements.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

The right approach by Marius Matei

I think that presenting DDD by examples and real projects is the best approach to share DDD experience. In our company we did more than 20 Java/web applications using DDD and we still discover the positive effects of the DDD approach in an organisation. This presentation is classic and we may find interesting focused ideas like incremental development. About Hexagonal architecture, I think that it is very useful while you want to manage complexity in big organizations.
We compiled our DDD experience here: www.seedstack.org/guides/design/ddd-pitfalls-an...

Re: The right approach by Erik Gollot

Yes interesting but I'm always surprised with the fact that some people discover that discussing with the business and use the business concepts to build an application is something that works.
What do they do if they do not do that ?!
All theses practices exist for a long time, before agile or DDD...but people have forgotten them. Normal when some people though away the "methods", sometimes with good reasons but without all required discernment.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT