Imagine a team developing to a specific business domain. We use languages to communicate with the client, company and within the team. We also use programming languages to develop the software. And still, we want our code to express, no only a correct syntax for that language, but the knowledge of the business domain in which we are developing. What if it was possible to capture the business meaning and transforme it into a language? This talk is about DSLs, it's architecture, business use, and also how to implement and test them.

1. WHAT IF
YOUR APPLICATION
COULD SPEAK?
Domain-Specific Language concepts, applications and implementation.
An introduction to Language-Driven Development.
Marcos Vinicius
@bymarkone

2. Imagine you have a problem to solve …

3. SUPPLY CHAIN MANAGEMENT
The complexity of inter company documents exchange

4. THE NEEDS
Translate Documents
Transfer Documents

5. Was not satisfactory for this context - too much work!
Altova MapForce - the best solution we found

6. Document oriented
data model
Set of rules that
convert an layout to
another
A repository of
identified layouts
Several helper
functions to help
with the task
An idea
to solve
the problem

7. Will it work?
After three months - Huge architecture effort spent,
not a single functionality, people lost in system complexity

8. A language with the semantics of the Document Translation
Domain that allowed us to succeed, and to be really faster
We decided to create a…

9. Domain-
Specific
Language
FileTransfer
Banking
Contract Management
Financial
Accounting
Supply Chain
Lexical
Analysis
Syntax
Semantics
Grammar
Alphabet

17. A new era arrived

18. BUSINESS LEVEL
How The Language-Driven Approach Can Change Business

19. OTHER DSL
!
▫︎A DSL to query Document
▫︎A DSL to program inside Documents
▫︎A DSL to configure Rules for file transfer
▫︎A DSL to configure networks of Documents
▫︎A DSL to configure security and access

20. META-LANGUAGE
!
▫︎A language that defines a language
▫︎Define name of the objects and verbs of your language
▫︎Define adjective, if they are mandatory, their datatype
▫︎Allows you have feedback of language syntax in parsing
▫︎Validate a language semantically
▫︎Provide auto-generated APIs documentation
▫︎Provide information for client IDEs

21. LANGUAGE TEMPTING
!
▫︎A feature that allows you to simplify the language that
the end user can access
!
!
!
!
!
▫︎Granular functionality and modularisation
▫︎On Demand combination to build complex operations
define User “bymarkone" with e-mail “bymarkone@tw.com“;
create Account for “bymarkone”;
activate Account, User “bymarkone”;
send confirmation to "bymarkone"
define and activate User "bymarkone"
becomes

22. BUSINESS SCRIPTING
!
▫︎When we have large amount of tasks
▫︎E.g. Configuring a new account with N users
▫︎E.g. Setting up a system
▫︎E.g. Sending download instructions to several clients
▫︎Speed in implementation of even complex systems

23. DEMOING
!
▫︎Build N scenarios for demoing you application
▫︎End users can understand the language and play with
scenarios

24. ANALYSIS LEVEL
Language Oriented Analysis

25. add User “Robespierre”;
add User “Rosseau”;
!
“Rosseau” invites “Roberpierre”;
“Robespierre" accept invite from “Rosseau"
“Rosseau” create group “Vive la France!” with tag “Liberté, égalité, fraternité”
“Robespierre" post in “Vive la France!”, message “Let's meet next 14th and kill the king!”
!
“Roberpierre" list friends;
“Rosseau" add message "People who know little are usually great talkers, while men who
know much say little”;
!
“Rosseau" add message “I am sorry to inform you all that our friend and compatriot
Roberspierre was guillotined. This bloody revolution is changing out country at a very
high price. ”
Let’s do a Social Network System

26. ARCHITECTURE
LEVEL
Language Oriented Architecture

27. API'S
!
▫︎REST API - A set of URL’s (names) and Actions
▫︎Must be expressive
▫︎Limited - beyond crud, has only HTTP verbs
▫︎With a rich language is hard to draw an API that is as rich
▫︎Expose and API (it can be rest) for language processing

28. USER EXPERIENCE - UX
!
▫︎Should be build in top of the language
▫︎We don’t care how modern and visual is the design, as
long as it talks the domain language
▫︎E.g. SQL is a DSL on data query and manipulation - how
many UI’s are built in top of that?
▫︎Will an editor with auto-complete and validation work?

29. TESTING
!
▫︎Unit, integration, component and contract test the
application (independent of the language)
▫︎Add tests for language processing - parsing and
interpreting
▫︎Add tests for language processing feedback
▫︎Add tests for domain and service executing through DSL

30. OVERALL ARCHITECTURE
!
▫︎UI Layer
▫︎Web Layer (REST)
▫︎Language Processing Layer
▫︎Domain/Services Layer
▫︎Infrastructure Layer
UI Layer
Web / Rest Layer
Language Processing
Domain Layer
Infrastructure Layer
From Martin Fowler’s DSL

31. PROCESS LEVEL

32. COMMUNICATION
!
▫︎The DSL is the language of communication of business
▫︎Devs, QA, BA, PO, Business Specialist, even Stakeholders
▫︎Ubiquitous Language
▫︎“Semantic Meetings” to understand and refine words of
the language, and their meaning

33. DOMAIN-DRIVEN DESIGN
!
▫︎Important to start the discussion about Domain
meaning - Entities, Services, Aggregates, Value-Objects
▫︎Design and Domain are emergent - they are created/
refactored with the development of the application
▫︎Create the DSL
▫︎Create the Semantic Model - connected to the DSL
▫︎Semantic Model is different than the Domain Model -
the first is a subset of the second.

34. PROGRAMMING
LEVEL
The fun of building a language

35. OVERALL OF LANGUAGE PROCESSING
Lexical
Analysis
Parsing
Semantic
Analysis
Text Tokens AST
Abstract
Syntax
Tree
Code
Generation
Semantic
Model

36. grammar IML;
!
program : (functionDecl | stat | expr)+;
functionDecl : type ID LP formalParams? RP block;
formalParams : formalParam (COMMA formalParam)*;
formalParam : type ID;
type : (DOUBLEDECL | INTDECL | STRINGDECL);
varDecl : type ID (EQUAL expr)? SEMICOLON ;
block : LB stat* RB;
assignment : expr EQUAL expr SEMICOLON;
conditional : IF expr THEN stat (ELSE stat)?;
returnstat : RETURN expr? SEMICOLON;
stat : block
| varDecl
| conditional
| returnstat
| assignment
| expr SEMICOLON
;
expr : functionExpr // f()
| arrayExpr // g[]
| unaryOpExpr
| expr binaryOp
| idExpr
| intExpr
BNF GRAMMARS

37. ANTLR

38. LANGUAGE LEVEL
Expanding horizons of our thought

39. Grammars
Alphabets
Languages
Syntactics
Semantics
Compilers
State Machines
Regular Languages
Context-Free
Grammars

40. PHILOSOPHICAL
LEVEL
Languages and Thought

41. “Because language does not mimic the world, you can do things
with it that are impossible under the law of physics. You are a god
in language. You can create. Destroy. Rearrange. Shove words
around however you like. You can make up stories about things
that never happened to people who never existed. You can push a
camel through the eye of a needle. It’s easy if ‘camel' and ‘needle’
are words.
In language, mortality does not tick relentlessly. You can conceive
of yourself as alive forever. Or you can imagine yourself dead. And
then alive again. You can live, die, live, die, live, die, live.”
The First Word: The Search for the Origins of Language
Christine Kenneally

42. Imaginary
Virtual
Real

46. Understand the Power of Languages,
Domain-Specific Languages,
for your project, architecture and
business

47. Language-Driven Development
Define a DSL that is going to represent the whole set of functionalities
that your application communicates with the external world.
Build this DSL in top of your high-level language, this second will
implement the more broad domain logic of your application.
Design your architecture, UX, ubiquitous language, meetings with
business, testing, external APIs… in top of that DSL.
This DSL is going to be the language your application speaks

48. For questions or suggestions:
!
Marcos Vinicius
@bymarkone
github.com/bymarkone
THANK YOU