[wangvnn]

We already have to deal with this in current state of Class Oriented Programming. Every class does something, none of them say anything about how the program work at run-time as a whole. So bad naming (cleverly bad) just adds on so much trouble in. Good naming from the domain helps, but it can not carry the program that far since it only addresses things at low level. At the architecture level, the class hierarchy still in control.

e.g. http://www.cs.unc.edu/~stotts/GOF/hires/chap1fso.htm "An object-oriented program's run-time structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program's run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa."

[hinkley]

Someone I read about code maintenance and/or quality years ago asserted that if the code uses different concepts than the domain the software is designed for, then you have intentionally built an impedance mismatch into your project and you're gonna have a bad time.

I haven't read enough about DDD to know if he was just a precursor or onto something else, but it does seem to map well to my least comfortable work situations.