Preface

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.