Speaking the Domain Language

Dave Thomas: Since we wrote the book I came across a good example of programming close
to the domain. A company
makes software to test telephone switches. The software is hundreds of thousands of lines
of C++. You configure the software for the switch being tested. It inputs signals and checks
for the correct output. Previously, whenever a new switch came along, they had to
alter the main program and recompile 800,000 lines of C++ to support the new switch.
Now they use the Ruby scripting language. Ruby has a very simple interface to C++ that
makes C++ objects look like Ruby objects. They wrapped their entire test suite in Ruby, so
they can access it by writing a Ruby program. They now have a library and wrapper code.
When a new switch comes along, they write a 50 line Ruby program to drive it. The Ruby
program is a domain-specific language that happens to use this boatload of C++ code in the
back end. To support a new switch, they now write code at the domain level.
And they find that's made them infinitely more productive.

Andy Hunt: A domain language is just another level of leverage. Just as C is a layer
of leverage above assembly language, Java is above C++, a domain language is above Java.
A domain language is just one more layer in a stack that gets more and more abstract from
assembly up to the domain level.

Bill Venners: Ruby is a general language in which I can program anything. To me,
a domain language is specific to a particular kind of programming task, such as testing
switches. How was Ruby their domain language?

Dave Thomas: Because in Ruby, I can write code that would say things like, "For
each line in the input set, set the status to high." I can actually write code in Ruby that looks
very domain specific.

Andy Hunt: So they might say: "For each phone line, snap relay on." The phrase we
actually use is, "Program in a language close to the domain." You can do that with macros
in C. You want code you can read. You want code you could show to a business
person and maybe they'd understand roughly what you're talking about.
You want to talk in their language, not the computer language.

Dave Thomas: That's a very good test. If you show the code to the customer and they
understand it, at least in principle, then you're programming at the right level.

Andy Hunt: There might be some control flow that the business people don't
necessarily understand, but in general, you want them to know what
you're talking about. You want to be closer to their language than the computer's language.