In spring 2001 the company I work for, Anshinsoft (http://www.anshinsoft.com), made a foray into enterprise application development for one of the largest securities brokers and asset management firms in the Asia-Pacific region. The process stimulated my interest in the challenges of modeling a specific problem domain and translating the model into real-world implementation artifacts. Since then, it’s been a long journey through the pages of Eric Evans’ domain-driven design book (Domain-Driven Design: Tackling Complexity in the Heart of Software), the teachings of Josh Bloch on designing good APIs (How to Design a Good API & Why it Matters; http://www.infoq.com/presentations/effective-api-design) and Martin Fowler’s preaching on domain-specific languages (DSLs).

The purpose behind a well-designed DSL is to provide a humane interface to your target users. The best way to do that is to have a programming model that speaks the language of the domain. For way too long we’ve been developing applications that are like a black box to business users. Believe me, every user would love to have a look at the business rules that you model in your code base rather than having to scramble through the boxes and arrows on a whiteboard.

The rules embedded in your code need to be comprehensible to the user. They need to be presented in a language that the user understands. This is what I realized in the 10 years I have spent working in domain modeling. When the rules are comprehensible, a DSL shines, communication between the development team and the business users becomes more effective, and your software becomes more expressive to your users.

An implementation language plays an important role any time you want to provide expressive syntax and semantics to your users. We’ve seen the phenomenal growth of an ecosystem that fosters expressive language development. Ruby, Groovy, Scala, and Clojure have been forerunners in encouraging developers to write more succinct yet expressive code. I’ve been programming in all these languages and I feel that idiomatic code written in any of them can be much more domain-friendly than most of their predecessors.

Writing a book on DSLs has been a challenge. I tried to focus on everything that’s real-world about DSLs. That’s why I chose a specific domain upfront. As the book progresses, you’ll feel how the domain models grow in complexity as business requirements add up. This helps you appreciate how a DSL-driven development approach scales up with the added complexity of the problem domain. There’s nothing radical in the approach; a DSL only encourages you to add an extra dimension to your thought process of API design. Remember, it’s your users who’ll be using the DSL. Please keep them in mind and you’ll be successful!