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.
