This document discusses drytools, a code generation tool that aims to reduce repetitive work. Some key points: - Drytools uses a domain-specific language (DSL) to define project structure and generate code for models, APIs, clients, and more based on these definitions. - The DSL allows defining models with properties, queries, and relationships. APIs can then expose CRUD and custom endpoints for these models. - Drytools generates common middleware like security and sign in functionality based on annotations in the DSL. - It produces a full-stack application including a web client, mobile clients, and API mocking for development. - Benefits include increased speed, enforcing best practices, and

1. Increase your
performance and code
quality
scaffolding and MDD
Vesin Dusko:
vesindusko@gmail.com
@vesindusko

2. Reality check
• By 2019 there will be 26.4 million software
developers, it is the fastest growing profession in
the world with 46% growth.
• But that is not nearly enough. In Germany alone
there are 40000 unfulfilled positions at this moment
• IT is the fastest changing industry
• Startups and agile pose a new challenge

3. Better yourself
• master things that you do every day (language,
frameworks, best practices,IDE, etc.)
• read, learn, experiment with new things
• centralize your knowledge, make it reusable
(libraries, frameworks, tools, scripts, plugins…)
• impostor syndrome
• repeat until you are in the business

4. Automate yourself
• No matter how good you are, you have only
two hands and one keyboard.
• Automate your processes (build,
deployment, etc. )
• Available scaffolding tools… (Spring Roo,
Ruby on Rails, JHipster, Bower, Gulp,
Grails, etc)
• Can we do more? Refuse to do repetitive
work!

5. MDE, MDD & MDA
• “Model-driven engineering (MDE) is a software development
methodology which focuses on creating and exploiting domain models,
which are conceptual models of all the topics related to a specific
problem.”
• “Model-driven development (MDD) is an approach to software
development where extensive models are created before source code is
written”
• “Model-driven architecture (MDA) is a software design approach for the
development of software systems. It provides a set of guidelines for the
structuring of specifications, which are expressed as models.”
• Model - “The model-driven architecture approach defines system
functionality using a platform-independent model (PIM) using an
appropriate domain-specific language (DSL)”
• Generator - “Code generation means that the user abstractly models
solutions, which are connoted by some model data, and then an
automated tool derives from the models parts or all of the source code for
the software system.”

6. drytools
don’t repeat yourself
• Multi module project generator
• Written in Scala
• drydsl (readable, optimal …)
• dryvalidation
• drypostprocessor
• drygenerators (maintainable, customisable…)

7. drytools DSL
project_name project[settings](
service_name server[settings](
property_name property[settings]…
model_name model[settings](
properties …
uniques and indexes …
queries …)
api_name api[api settings](
endpoint_name endpoint[settings] …)
)…
web_app_name web[settings] …
android_app_name android[settings] …
ios_app_name ios[settings] …
)

8. Models
Role enum(USER, MODERATOR, ADMIN)
User model [type sql](
id long(primary key)
username text (min 6, max 20, unique)
passwordHash text (min 128, max 128)
firstName text (min 2, max 60)
lastName text (min 2, max 60)
gender enum(MALE, FEMALE)
role Role (default USER)
birthDate optional date
findAll from User
findById from User where User.Id == id
findByUsername from User where User.username == username
findByFirstName from User where User.firstName == firstName
findByLastName from User where User.lastName == lastName
findByGender from User where User.gender == gender
findByRole from User where User.gender == gender
findMaleUsers from User where User.gender == “MALE”
findAdminUser from User where User.role == “ADMIN”
findByName from User where User.firstName like name or User.lastName like name or
User.userName == name
)

9. ModelsRole enum(USER, MODERATOR, ADMIN)
User model (
username text (min 6, max 20, unique)
passwordHash text (min 128, max 128)
firstName text (min 2, max 60)
lastName text(min 2, max 60)
gender enum(MALE, FEMALE)
role Role (default USER)
birthDate optional date
findMaleUsers from User where User.gender == “MALE”
findAdminUser from User where User.role == “ADMIN”
findByName from User where User.firstName like name or User.lastName like name or
User.userName == name
)

10. Role enum(USER, MODERATOR, ADMIN)
User model (
username text (min 6, max 20, unique)
passwordHash text (min 128, max 128)
firstName text (min 2, max 60)
lastName text (min 2, max 60)
gender enum (MALE, FEMALE)
role Role (default USER)
birthDate optional date
findMaleUsers from User where User.gender ==
“MALE”
findAdminUser from User where User.role ==
“ADMIN”
findByName from User where User.firstName like
name or User.lastName like name or User.userName
== name
)
Owner model (
user User (unique)
findByUser from Owner where Owner.user == user
findByIdWithUser from Owner with Vet.user from
Owner
findPetsByOwnerId min Pet where Pet.owner from
Pet where Pet.owner == owner
)
Vet model (
user User (unique)
findByUser from Vet where Vet == user
findByIdWithUser from Vet with Vet.user from Vet
findVisits from Visits where Visit.vet == vet
)
PetType enum (DOG, CAT)
Pet (
owner Owner
type PetType
birthDate date
description text (max 1024)
)
Visit (
Vet vet
Pet pet
date date
note text[max 1024]
findByIdWithVetAndPet from Visit with Visit.vet
from Visit with Visit.pet from Visit where Vet.id == id
)

11. Middleware
• Services
• Security
• Simple security -security (principal User)
• Role security - security (principal User, role Role)
• Permission based security - security (principal User, action UserAction)
• SignIn
• Username - signIn (username)
• Email - signIn (email)
• Google - signIn (google)
• Facebook - signIn (facebook)

12. APIsUserApi api(
adminUsers find [query User.adminUsers, secured ADMIN, rest "/admins"]
users find [query User.findAll, response (User.id, User.email, User.firstName, User.lastName), secured, rest
"/users"]
nonAdmins find [from User where User.role != "ADMIN", secured, rest ]
user crud [model User, secured ADMIN, rest]
)
OwnerApi api(
owner crud [model Owner, secured ADMIN](
user.firstName [save default "Petar", update default "Pera"]
user.lastName [min 30, max 40]
address [visible (create, read) ]
user.email
notes optional text[min 2, max 10]
)
owners find [from Owner with Owner.user as User from Owner where optional Owner.address like address
response (Owner.id, User.email, User.firstName, User.lastName), secured ADMIN, rest “/owner]
ownersPets find [ from Owner with Pet.owner from Owner with Owner.user from Owner where Owner.id ==
ownerId response (Pet.id, Owner.id, Pet.name), secured, rest “/owner/:ownerId/pets"]
……

13. APIs…
myPets find [from Owner with Pet.owner from Owner with Owner.user from Owner where Owner.user ==
principal, rest, secured]
PetWithOwnerName dto(
Pet.name
Pet.petType
User.firstName
User.lastName
firstPet enum(YES, NO)
)
PetDto dto(Pet.id, Pet.name)
VetWithSpecialties dto(
User.firstName
specialties list VetSpeciality.name
pets list PetDto
)
vetsWithSpecialties custom [request PetWithOwnerName, response list VetWithSpecialties, secured
ADMIN, get "/vets"]
vetInfo custom [request dto(Vet.id), response VetWithSpecialties, secured, get "/vet/:id", transactional
sql]
)

14. Clients
• web client (AngularJS, Bootstrap, Yeoman,
Grunt, Bower) with ApiCaller and ApiMock
• iOS client with ApiCaller and ApiMock
• Android client with ApiCaller and ApiMock

15. What's next?
• New DSL features
• Push Api
• Web sockets
• UI components
• Android and iOs notifications
• Big data analysis with spark

16. Pros/Cons
• Pros
• speed up to 5x
• best practices
• architecture as a code
• refactoring
• global improvements
• learning tool
• we are in control
• Cons
• controversial technique
• hard to implement
• hard to balance
• maintenance
• not suitable for every case

17. Thank you.
Questions?