I'm at Software Development West this week. My brain always hurts by the end of the week (this is my eighth SD) but right now that pain is far off. First up is a half-day tutorial on Domain Driven Design presented by Eric Evans (author of the book by the same name that is sitting in my to-read pile). In some ways this has been a morning of "yup, knew that, of course, doesn't everybody", since the whole point of OO is that we can program in the terms of the problem rather than the terms of the technologies and languages being used to implement the solution. One big point that Eric makes, though, is that developers tend to dive down into implementation details as soon and as fast as possible, but that we need to stay up at that higher level domain view that the business experts understand. (Because everybody knows that business experts don't understand pointers and database tables and n-tier application stacks...or worse, they go off and learn all that stuff and then start delivering requirements docs as schemas and UML! <g/>)

To quickly summarize a four-hour session into something like four sentences:

• Design should be in terms of business concepts.
• A primary goal of domain driven design is to develop an ubiquitous language - a language that is used by every member of the team to talk about every aspect of the project. On one project that Eric worked on, they made a significant change to their model that caused their not-the-original release date to slip another three weeks. This change, however, brought about a language that became so ubiquitous that marketing used terms from the model to talk about their product!
• A model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
• A model serves a particular use. It does not have to be as realistic as possible. It does have to allow software to enter the domain. An example Eric gave of this is the well-known Mercator projection map of the world. This map is useless for comparing relative sizes of land masses, but if you want to navigate between land masses it's just the ticket.
• A model is irrelevant if it isn't reflected in code.
• Models that reflect their domain don't have classes that end in "or" or "er". <g/> For example, a design to handle monetary instruments would talk about assets and accrual schedules, not accrual calculators.

*** Comments, questions, feedback? Want a fun job on a great team? I need a tester! Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. Great coding skills required.