Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Introducing DDD in a Project at “Which?”

Introducing DDD in a Project at “Which?”


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


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.

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

Community comments

  • The right approach

    by Marius Matei,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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:

  • Re: The right approach

    by Erik Gollot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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