In the first edition of Extreme Programming Explained: Embrace Change, Kent Beck introduced the "Metaphor" practice, also called "System Metaphor."
Each XP software project is guided by a single overarching metaphor. Sometimes the metaphor is "naive," like a contract management system that is spoken of in terms of contracts and customers and endorsements. Sometimes the metaphor needs a little explanation, like saying the computer should appear as a desktop, or that pension calculation is like a spreadsheet. These are all metaphors, though, because we don't literally mean "the system is a spreadsheet." The metaphor just helps everyone on the project understand the basic elements and their relationships.
The words used to identify technical entities should be consistently taken from the chosen metaphor. As development proceeds and the metaphor matures, the whole team will find new inspiration from examining the metaphor.
The metaphor in XP replaces much of what other people call "architecture." The problem with calling the 10,000-meter view of the system an architecture is that architectures don't necessarily push the system into any sense of cohesion. An architecture is the big boxes and connections.
You could say, "Of course architecture done badly is bad." We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks. By asking for a metaphor we are likely to get an architecture that is easy to communicate and elaborate.
Kent Beck, Extreme Programming Explained: Embrace Change
This didn't work out so well. Detractors of XP latched on to System Metaphor as an example of XP's irresponsibility: of course architecture is important! How could it not be? How could this silly idea of "metaphor" replace architecture?
On the flip side, people who liked and used XP struggled to understand the idea of System Metaphor and its place in XP. Early XP conferences had whole workshops devoted to coming up with a metaphor for your system. Its meaning and purpose was debated on Ward's Wiki, source of the best and most complete early information on XP. On my first XP project, the one where tried everything religiously, we dabbled with system metaphor, too, giving our classes names like "forklift" and "warehouse." (Our system was a data warehouse, you see. Except that it wasn't.)
Most people just ignored System Metaphor. Kent Beck stuck with it for a while, but eventually dropped it as well. When the second edition of XP Explained was published, System Metaphor was gone, with nothing to replace it.
Meanwhile, Joshua Kerievsky had created Industrial XP (IXP). IXP never really caught on, possibly because the name was so similar to the name of Joshua's company, Industrial Logic. It was a good method nonetheless. I had the opportunity to coach a team in its use as part of an long-term coaching effort in Toronto.
Joshua was a reviewer for Eric Evan's excellent book, Domain-Driven Design. It's probably no coincidence that Domain-Driven Design is an explicit practice in IXP. The IXP web site quotes Evan's book to describe the practice:
The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process. Domain-Driven Design fills this need.
Eric Evans, Domain-Driven Design
I think domain models are an excellent tool and Eric's book is wonderful. Domain models aren't appropriate in all situations, though, which is why we didn't include domain-driven design as a practice in our book. Instead, we used another pattern from Eric's book: Ubiquitous Language.
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of the design.
The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing.
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Eric Evans, Domain-Driven Design
As I look at the IXP site now, I don't see any reference to Ubiquitous Language. But I seem to remember that it was a major part of that project in Toronto. That's probably why it was on my mind when I mentioned it to Shane as a possible practice for The Art of Agile Development.
Programmers program in the language of technology: classes, methods, algorithms, and databases. Domain experts talk in the language of their domain: financial models, chip fabrication plants, and the like.
You could try to translate between the two languages, but it will add delays and errors. You'd produce some software eventually, but you'd probably introduce some bugs along the way. Instead, pick just one language for the whole team to use--a ubiquitous language.
James Shore and Shane Warden, The Art of Agile Development
So here we are, full circle. The core idea of System Metaphor was to "give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks." (Beck00) And the core idea of Ubiquitous Language is to "reflect in code how users think and speak about their work." (Shore07)
Right back where we started, except without that funky metaphor stuff.