Recently a friend discovered this blog. She asked me why do I write so much about Expressive Design. This is not the first time I’m asked this so I decided to write down my answer. I will try to give some overview of the topic and link to the many articles in this blog about specific points.

Expressive design is a big deal for me. There are many ways to design systems and over the years I’ve been to too many development teams where design that requires too much translation caused big problems. Companies where developers are not supposed to understand the domain often have the worst code bases and lowest productivity; all caused by the laborious process required to convert business concepts into code and vice-versa.

For many years technology limitations were the main excuse for writing code and systems that don’t look or feel like the domain. Those limitations are long gone; today’s high-level language and platforms and efficient runtimes enable developers to invest most of their time in the domain instead of solving implementation details.

In my experience the best way to write expressive code is to heavily apply the Ubiquitous Language and supporting patterns that form the core of Domain-Driven Design; all way down from the architecture to production code and tests.

Greenfield code bases have no excuse to ignore those techniques. Legacy system integration and evolution, though, can be tricky. When some code is already in place we need a way to quickly visualise how far away from the actual domain it is.

A while ago I’ve started using tag clouds to visualise expressiveness. This technique became quite popular, featured in several articles and presentations by people interested in architecture and visualisation.

When you perform this gap analysis you’ll often find that poor layering and component definition cause most problems.

Even simple refactorings can bring the domain to the surface. When you have to integrate with some system that can’t be refactored, though, it is extremely important to identify the multiple domains and languages in place and required mappings from one to another.

Surely those principles and techniques don’t apply for all systems but I do believe that most of what people develop these days will really benefit from aiming for expressiveness and clean design. Mary and Tom Poppendieck said it all:

[…]when you compare the skyrocketing cost of maintenance with the relentless increase in processing power and its decrease in price, the rationale for [extremely efficient] architectures makes little sense. These days there is rarely an excuse to sacrifice ease of change for execution speed, with the exception of some embedded or network-intensive software.