Finding the Right Metaphors

In his book, Domain Driven Design, Eric Evans said that there really is no such thing as complexity, as complexity happens when we diverge from our models or when we use metaphors inconsistently, and I tend to agree. Very involved systems can be easy to understand as long as they adhere to an appropriate set of metaphors.

So how do we find the right metaphors for the problem at hand?

It’s actually easy because we naturally think in metaphors, to begin with. Any problem we express is already defined in some form of abstraction or metaphor, so our primary task is to group different pieces together in ways that make sense to us. We do this by simply asking, “What is the same about these different pieces?” and “What is different about them?”

If we think from the user’s perspective we can often get a good sense of the domain model and then drive down to implementation. Design patterns can be used to group concepts in ways that support our goals.

I have an architectural pattern I use related to this that I called “the three layer DIP” (DIP stands for dependency inversion principle). The application or domain layer is the top level, below that is the services layer, and below that is the platform layer. The idea is that the domain layer only makes calls to the services layer and the services layer only makes calls to other services or the platform. For many kinds of applications, this is a good framework to work within because it makes the domain model clear at the application layer.

The metaphors we use in an object-oriented system are composed of objects. Every object in the system should have its own perspective in the world and should know only enough to accomplish its specific tasks. Separating out perspectives in software gives us the ability to hide different parts of the system so we can make changes without those changes rippling out into other parts of the system. This limiting of knowledge gives software the ability to be more changeable.

Of course, metaphors mean nothing to a computer, but the primary goal of writing software isn’t to make a computer do something, that’s secondary. The primary goal of writing software is to communicate our designs to other developers. Since the dawn of civilization, metaphors have been one of the most powerful ways to communicate ideas. Incorporating metaphors in our software designs helps us communicate complex ideas in our code.