These are the slides of my talk at Code Generation 2010. I share my experiences during the development of a Model-Driven Software Factory. This factory is based on multiple Domain-Specific Languages (DSLs), together describing a Service-Oriented Business Application. All DSLs have a graphical concrete syntax and are aimed at involving domain experts in the software development process. The factory has been used for many projects in the last five years and its user base is growing fast.
10. Lessons learned
Product dev. starts with a customer need
MDD asks for repetition
First step in building a MDSF is domain
definition
Make a clear choice about your target user
Define the most important domain concepts
Think about a methodology early - it will
influence your DSL design and tool
11.
12. Browser
Styling & user interaction
CSS, HTML, JavaScript
Client-side logic
Server communication
JVM
Java
Flows & actions API & connectors
Access rules
ORM
Database
SQL
Data
13. Browser
Styling & user interaction CSS
Client-side logic
Rich Forms DSL
Server communication
JVM
Microflow DSL
Flows & actions API & connectors Mapping DSL
Access rules Security DSL
ORM Domain model
Database
Data
14. How to support our target users?
Model should be easy to
– Read
– Browse
– Search
– Keep consistent
Deployment
– Should be easy / non-technical
– Model execution / interpretation
– Cloud infrastructure
15.
16. Lessons learned (1)
Interpretation is a viable alternative for code
generation
Use model checks to prevent errors early
Make sure you can navigate and search
Make DSLs as declarative as possible
Prevent property explosion
Create flexibility for unforeseen uses
17. Lessons learned (2)
Do not only focus on development phase
Deployment can be slow – compliance with
code style, architecture, server config, etc.
Cloud infrastructure can automate
deployment
Grow your factory bottom-up
Always look at existing standards first
25. Lessons learned (1)
Put effort in documentation, training, and
templates
Create flexibility to prevent double release
cycle troubles
Release management is much easier with a
plugin infrastructure
Be always backwards compatible
26. Lessons learned (2)
Deprecate model structures and provide
alternatives for breaking changes
Create (semi-)automated tests using test
models
Learn from reported bugs
Do not only test the technical implementation
32. Lessons learned (1)
Make it compelling for partners to use your
product – what’s in it for them?
Start doing lighthouse projects yourself
Sell business solutions to business people
Eat your own dog food
Integrate ‘community tools’ in modeling
environment
33. Lessons learned (2)
Use a reputation system for your support
forum
Give partners incentives to build reputation
Create a place to download an share
templates, extensions, etc.
Make it compelling for partners to publish
content