This document discusses Behavior Driven Development (BDD) and Domain Specific Languages (DSLs). It defines BDD as a formalized approach to effective communication between project teams using behavioral specifications, backlog items, acceptance tests and a ubiquitous language. DSLs are described as computer programming languages with limited expressiveness focused on a particular domain. The benefits of DSLs include improved productivity by making code easier to read and understand and avoiding duplication. DSLs can also help communicate with domain experts by providing a language for their domain. Potential problems with DSLs include lack of experience using or developing them and not having resources for the time required.

1. BDD DSL
как формализованный способ
построения эффективной коммуникации
между всеми участниками Delivery and
Value Team
Anton Semenchenko
ISSoft

2. BDD
Behavior-Driven Development
• Behavioral specifications
• Backlog Items
• Acceptance test as a part of Definition of Done
• Specification as a ubiquitous language
• TDD Test-Driven Development
• Tooling principles
• DSL
• User stories
• Story versus specification

3. DSL
Domain Specific Language
A computer programming language of limited
expressiveness focused on a particular domain.
• Computer programming language
• Language nature – sense of fluency, structure
• Limited expressiveness - a bare minimum of
features to support its domain. It’s impossible
to build entire system in a DSL; you use a DSL
for one particular aspect of the system.
• Domain focus – clear focus on a small
domain.

4. DLS – 3 main categories
• External DSL- SQL, Regular Expressions,
AWK, XML (for configuration BI and
Mockup frameworks)
• Internal DSL – Lisp, Ruby … Flow DP
• A Language workbench
• Fragmentary (external – regular
expressions; internal – Mock frameworks)
• Stand-alone DSL’s

5. Boundaries of DSLs
•Language nature
•Domain focus
•Limited expressiveness
• The domain focus isn’t a good boundary condition – the
boundaries more commonly resolve around limited
expressiveness and language nature.

6. Architecture of DSL processing
•DSL script
•Parse
•Semantic model
•Generate
•Target code

7. “Low” level details
• In thisour point of view a DSL is a front-end to a
library providing a different style of manipulation
to the “std” command-query interface.
• In this context, the library is a Semantic Model of
the DSL.
• Without code generation- “interpretation
language”
• With code generation – “compilation language”
• Efforts to build DSL is usually much smaller than
for building the underling model.

8. DSL – Why?
•Improving development productivity
1. The easier it is to read a lump of code, the easier it is to
find mistakes, and the easier it is to modify the system.
2. The limited expressiveness of DSL’s makes it harder to
say wrong things and easier to see when you’ve made
an error.
3. Avoids duplication by gathering together common
code.
4. Provides an abstraction
5. DSl can help learn how to use API – how to combine
“call’s” together.

9. DSL – Why?
•Communication with Domain experts
1. Provides language for communication with Domain
experts
Notes: Only subset of DSL’s could be used for this
purpose (for example regular expressions can’t)
2. Write and READ DSL code
3. Involve Domain experts on building a model
4. Involve Domain experts on building a ubiquitous
language
5. Note: Trying to describe a domain using a DSL is useful
even if DSL is never implemented. It can be beneficial
just as a platform for communication

10. Problems with DSL’s
•There is no experience in DSL
usage
•There is no experience in DSL
development
•There is no resources for “time
consuming” DSL development

11. Problems with DSL’s
• A huge set of DSL’s inside one project
Incremental costs of learning the DSL is quite small compared to
the cost of understanding model.
• Cost of Building (another point of view)
A DSL may be a small incremental cost over its underling library,
but it’s still a cost.
The cost of DSL is the cost over the cost of building the model.
A DSL may help think about the model and reduce cost of
building it.
• Too specific Language
Make sure you have a clear sense of what narrow problem the
DSL is focused on.

12. Real life example
•2 independent phases
•2 independent contracts
•2 absolutely different solutions

13. Real life example
• General “business” context
• Current “business” context
• General “technical” context
• Phase 1
• Solution 1 – “classical”
• Pros and Cons
• Phase 2
• Solution 2
1. Ubiquitous language
2. BDD
3. 3 Models (State Machines)
4. 3 DSL
• Pros and Cons (almost for free)

14. Anton Semenchenko
Skype: csi.AntonSemenchenko
Cell: +375 44 74 00 385
+375 33 33 46 120
ISSoft
AntonSemenchenko@coherentsolutions.com
Thanks 