In Design Patterns are Code Smells I argued that Design Patterns are heavily influenced by implementation language. This should not be surprising, since design patterns are often translated directly into code. What about higher design abstractions? Surely as you get more distant from the code, the language dependency goes down. You wouldn't expect to see UML, or Domain-Driven Design, or Model Driven Architecture, totally colored by implementation language, would you?

In fact, you should. I have been reading a lot of software design and architecture books lately, and have come to two conclusions:

1. No matter how far you get from code, design and architecture is inevitably colored by the designer's knowledge of programming languages.
2. The design literature unintentionally creates a vicious lock-in around programming languages, as follows: Design books tend (even more than programming books) to fixate on the most popular programming language at the time they are written. Call it Language X. Enterprise developers need "lots of design", because they are writing "serious" code. Q.E.D., enterprise software must be written using X, because the design books (implicitly) say so. But this is not the designers' intent! Designers are not making proactive language recommendations. They are making reactive, lowest common-denominator choices in order to reach a broad audience.

I will be expanding on this topic at the Rails Edge in Chicago, August 23-25. In "Domain-Driven Design in Ruby," I will revisit the concepts in Eric Evans' excellent book, but with Ruby-colored glasses, and maybe even a bit of a Lisp. You can find the abstract here (scroll down).