It seems that the writers of GOOS don't value the metaphor in software engineering. They focus on the writing code that reflects the domain. They want word used to name variables, classes and other elements of the programming language to reflect what program is going to be doing from the end users point of view. In other words they want the code to reflect the "domain".
We write the acceptance test using only terminology from the application’s domain, not from the underlying technologies (such as databases or web servers
I think writing code in the language of the domain, is writing metaphors. In GOOS, the authors walkthrough creating an application that bids on auctions. They package the code that does the bidding into a class called
AuctionSniper because it is responsible for the functionality that tries to snipe auctions. It is part of a software system that sends messages to another software system. It could have just as easily been called
MessageSender or something like. Instead it is meant to represent someone who tries to just outbid people at auctions. You can say that the piece of code that sends to auction bids to the auction houses software is as an actual person at an auction lifting their paddle to bid. The code is an auction sniper.
When writing code to clearly express its intent we are writing metaphors. When we refer to some text as a
administrator we have a representation of the people in mind, the
user. But we don't say that this piece of text on the screen is the representation of the
administrator we say it is the
administrator. It would seem that Domain Driven Design could be called Metaphor Driven Design. If you want to be corny(and I do), you can also call it the design of the compressed proportion.
Maybe that's why naming is so hard in programming. What metaphor are we trying to find?