The second session I attended at this year’s NFJS in Chicago was on Domain Drive Design with Venkat Subramaniam - something that has held my interest for about a year now. I’m slowly understanding it more, letting it percolate in the back of my head. In that process, one concept that has struck a chord and tripped me up is the ubiquitous language.

The use of ubiquitous language is almost a no-brainer, once you’ve read what Eric Evans says about it. The tricky part seems to be how to get there, particularly how to include an entire I/S team and an entire client team so everyone is speaking the same language.

So, I asked Subramaniam exactly that. Here’s what I learned.

Subramaniam does not recommend sitting down and having an entire team design something. Instead, a pair of developers (pair programming) can sit down and design a feature. Developers should pair differently in short periods (daily, weekly, etc.). This causes the ubiquitous language to be cross-pollinated more readily as each pair works with the client on a feature and then switches up and works in a different area.

In addition to this, senior developers (leads) can assist in validating and cross-pollinating by “running” - jumping from pair to pair in the course of a day or week.

Good stuff, and definitely concrete information that at the very least can be tried and tweaked until it seems like the team and the client are starting to build and refine a domain specific ubiquitous language.

I jotted down a couple other notes to share.

1. Building what your customers “wanted” guarantees failure. Write what your customers “want” (present), not what they “wanted” (past).
   

2. Code reviews are good (especially peer code reviews). A code review should make you smarter (peer should point out an improvement) or make you a hero (point out something you did really well).