What are some practical uses for Domain Specific Languages (DSL)? And how do you go about designing DSLs, implementing them in Groovy, creating tests for your models and evolving the structure of the languages over time?
In this fast paced session, Peter Bell will examine a real world Groovy DSL, how it was designed and implemented, the testing strategies employed and the options for evolving the structure (grammar) of the DSL.
If you've built DSLs but want to go further, or if you've still not figured out how a DSL might help you to build better, more maintainable apps more quickly and easily, come along and learn more about creating practical, maintainable DSLs for your projects.
Just a thought . . . If you are interested in this talk you might also be interested in Core Gradle: Gradle, a Build System for Java Workshop and Graeme Rocher's Groovy and Grails Workshop
6. What is a DSL?
• Specific to single domain - generally not
Turing complete (excl. XSLT)
• More expressive than GPL within the
domain
• Executable
• Examples: SQL, CSS, Regex, PC
configurator, document workflow rules
Monday, May 17, 2010
7. What is a DSL? - DSL vs. API
• Subjective
• Often facade to API
• Focus on language nature
• “Fluent” interface
API: new event( startTime: "16:00", endTime: "18:00" )
DSL: new event.from 4.pm, to: 6.pm
Monday, May 17, 2010
8. What is a DSL? - Benefits
• Expressive (clear intent, concise)
• Separate business logic from code
• Separate lifecycle
• SME readable (not writable)
Monday, May 17, 2010
9. What is a DSL? - When Use?
• Frequently changing business rules
• Interactions with stakeholders
• Relatively well understood domain
• Typical use cases:
• Product family
• Platform based development
• Configuration
• Business rule definitions
Monday, May 17, 2010
10. Key Concepts
• Overview:
• Vertical vs horizontal
• Abstract vs Concrete
• Projections
• Three types of DSL
• Internal vs. External
Monday, May 17, 2010
11. Vertical vs. Horizontal
• Horizontal: technical domain
• SQL, CSS, GORM . . .
• More maintainable/readable code
• Good enough is good enough
• Vertical: business domain
• Insurance, PC configurator . . .
• Share “code” with SME’s
• Readability is key
Monday, May 17, 2010
12. Abstract vs. Concrete
• Abstract grammar <person>
• what say <FirstName>Paul</FirstName>
<LastName>King</LastName>
• Concrete syntax </person>
• how say new person( firstName: "Paul", lastName: "King" )
person called “Paul “, “ King “
Paul King
Monday, May 17, 2010
13. Projections
• Multiple projections
• Textual
• Spreadsheet
• Visual
• Form based
Monday, May 17, 2010
14. Three Broad Types of DSL
• Internal (embedded)
• External (parser)
• Language workbench
Monday, May 17, 2010
15. Internal vs. External
• Internal: • External:
• Easier to implement • Easier to evolve
• Power of GPL: • End user writable (forms)?
• Loops • Projectional:
• Math • Forms
• Conditionals . . . • Visual
• Refactor to external • Spreadsheet
Monday, May 17, 2010
16. Top Down/Bottom Up
• Bottom up:
• Evolve from API (e.g.
Hibernate)
• Not very expressive, but
quick starting point
• Top down:
• Sketch out UL with
stakeholders
• Generally better language
Monday, May 17, 2010
17. General Hints
• Learn from DDD/UL:
• Common, rigorous understanding
• Driven by domain model
• Involve to SME’s
• Lots of little languages (e.g. Grails)
• Bounded contexts
• Risk:
• DSL eventually becomes badly designed GPL
• Think: Ant
Monday, May 17, 2010
19. API
• Good starting point
• Easy to evolve
• Often readable enough . . .
Event salesMeet = new event( startTime: "16:00", endTime: "18:00" )
Participant Joe = new Participant( firstName: “Joe”, lastName: “Smith” )
Participant Fred = new Participant( firstName: “Fred”, lastName: “Jones” )
salesMeet.addParticipant( Joe )
salesMeet.addParticipant( Fred )
Monday, May 17, 2010
20. Fluent interface
• The start of DSLs
• Language nature
• Focus on sentence like syntax
Event salesMeet = new event( from: 4.pm, to: 6.pm )
.with( “Joe”, “Smith” )
.and( “Fred”, “Jones” )
Monday, May 17, 2010
29. Additional Considerations
• Testing
• Evolution
• Documentation
• Error handling
• IDE support
Monday, May 17, 2010
30. Testing DSLs
• Test domain model
• Test fluent interface
(expression builder)
• Can Compile
• Scenarios
• Orthogonal test DSLs
Monday, May 17, 2010
31. DSL Evolution
• The problem: success!
• Approaches:
• No changes
• Backwards compatibility
• Versioning
• Model migrations
Monday, May 17, 2010
32. Documentation
• Getting started guide
• Samples
• FAQs for common tasks
• Language reference
• Some debugging suggestions
• Not more than API requires
• Source/regression tests help but
aren't enough
Monday, May 17, 2010
33. Error Handling
• Throw while process = easy
• Meaningful messages hard
Monday, May 17, 2010
34. IDE Support
• Syntax highlighting
• Code completion
• Static verification
• IntelliJ helps . . .
• If important, consider Xtext/EMF
Monday, May 17, 2010
35. Conclusions
• It’s all about the domain
• Evolve to DSLs
• API to internal . . .
• . . . external if required
• Check Guillaume’s preso
for syntax
• Think about additional
considerations from day 1
Monday, May 17, 2010
36. Resources
History:
http://www.faqs.org/docs/artu/minilanguageschapter.html
DSM:
JP Tolvanen: http://www.metacase.com/blogs/jpt/blogView
Steve Kelly: http://www.metacase.com/blogs/stevek/blogView
Markus Voelter: http://www.voelter.de/
DDD:
http://domaindrivendesign.org/
Monday, May 17, 2010
37. Resources (2)
DSLs:
Martin Fowler: http://martinfowler.com/dslwip/
Groovy DSLs:
Google - Guillaume Laforge, Paul King, Hamlet D’Arcy,Venkat Subramaniam,
Neil Ford
DSL Evolution:
http://www.infoq.com/articles/dsl-evolution
Books:
Domain Specific Modeling - Kelly/Tolvanen
Generative Programming - Czarnecki/Eisenecker
Domain Driven Design - Evans
Monday, May 17, 2010
38. The End!
• http://gettinggroovy.com
• Email: peter@pbell.com
• Twitter: peterbell
Monday, May 17, 2010