Tuesday, December 15, 2009

System Metaphors and Deep Models

The book that revolutionized my approach to software development was a thin white volume titled eXtreme Programming explained. As I began to implement what I read, I struggled, like many others, to understand the System Metaphor practice. Even though Kent Beck explained that "sometimes the metaphor is 'naive'" [p.56], I felt like I was missing something. Why didn't my systems have catchy metaphors like C3's assembly line?

As my voyage continued, I discovered Eric Evans' Domain Driven Design and his Ubiquitous Language pattern. "Use the [domain] model as the backbone of a language ... in all communication within the team and in the code" [p.26]. I realized that Kent had also recommended that "the words used to identify technical entities should be consistently [chosen]" [p. 56]. So I stopped worrying about elegant metaphors and focused on expressing the domain language clearly in my code.

During the past year, my open source work on .NET functional test tools has evolved a new domain model, one that Eric describes as a Deep Model. "A deep model provides a lucid expression of the primary concerns ... while it sloughs off the superficial" [p.190]. As I developed more abstract and powerful concepts, I found I needed some way to hang these new ideas on a mental framework that would keep them consistent and understandable. I started drawing terms from a simple hardware model: processor, operator, memory. I was developing a System Metaphor!

Now I understand that a metaphor is not something that I need to seek from the outset. I concentrate on developing and refining a domain model and using the model language ubiquitously. At some point, in some domains, a deeper model may emerge with more insightful and powerful concepts. A metaphor is often a useful aid to organizing and explaining these concepts, by allowing us to relate abstract ideas to elements in a common concrete domain.

No comments:

Post a Comment