Domain Specific Modeling, enabling full code generation
I finally took the time to read the book "Domain Specific Modeling, enabling full code generation" by Steven Kelly and Juha-Pekka Tolvanen. Yes, I know, I should have read this book earlier, but hey, I only have 24 hours a day. I wanted to read the book in detail because I expected a lot from it. It didn’t disappoint me!
In short: if you liked these articles on this blog:
- 15 lessons learned during the development of a Model Driven Software Factory.
- Best Practices for DSLs and Model Driven Development.
- DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design.
You just have to read the book to learn a lot more about Model Driven Development (MDD). Let me explain why.
Brief overview of the book
In part I the authors talk about the background an motivation of Domain Specific Modeling (DSM). They explain the need for Domain Specific Languages (DSLs) and also talk about the business value of changing the way we develop software.
Part II, fundamentals, explains DSM in detail. From language to models, from code generator to domain framework, etc.
In part III the authors show five examples of DSM. For each example they explain the reasons and objectives, the development process, and the results. They also show in detail the choices made during language and generator design.
Part IV is the most ‘in-depth’ part of the book and is packed with practical lessons and advices. All aspects of creating a DSM / MDD solution are covered in great detail. First all aspects of language definition are covered, including the maintenance of languages and the integration of languages. After that the authors talk about generator definition, followed by a chapter about domain frameworks. The process / methodology part is not forgotten and provides some nice checklists to help you decide for example if a domain is ready for DSM. They finish this part with an overview of tools for DSM, including a brief overview of the history and some remarks about reuse an model versioning.
Why I like the book
I really like the book, because:
- It is packed with practical advise, from high-level guidelines to detailed rules-of-thumb.
- Every aspect of DSM / MDD is covered (business value, architecture, language design, generator development, etc.).
- The content is rooted in industrial experience and scientific research (I like that combination!).
- The book is example-driven. Part IV is build on the examples provided in part III and uses them to explain the more abstract concepts.
I’m not asked to write this blog post, I just think you should buy the book and learn the details of all aspects of using Model Driven Development in practice. In my opinion this book belongs on the bookshelf of anyone serious about Domain-Specific Modeling, Model-Driven Development, Domain-Specific Languages or what other Model-Driven Engineering related term you use.
Have you read this book? What did you think about it?
3 Comments Added
Join DiscussionIt sounds like an interesting read to me. It’s interesting to read what the book is about and what you like about it, but what I am actually more curious about is what you’ve learned from the book š Are there any lessons in the book for you as an architect with a lot of experience in Model Driven Development?
Hi Arne,
Interesting question, thanks for asking.
First, it’s always good to have knowledge written down in a concise way even if you already know most of it. It’s even better if this knowledge is grounded on scientific research and clear industrial experience so you can strengthen your own knowledge / arguments. For me, this is applicable to part I and II.
From part III I learned lot about different ways to apply MDD. My experience is centered around one situation, in this part the authors share knowledge about different cases, teams, processes, etc.
The last part is really packed with practical advice. In some cases I recognized the advice from my own experience, in other cases I even learned the same advice the hard way (then you’re thinking, the book should have been written a couple of years earlier š ). But there was also a lot of stuff I didn’t know or didn’t think about before. Detailed advice for choosing modeling concepts for example, or a detailed comparison of generator strategies.
I want to give you an honest reply, but it’s a bit difficult to say what I exactly learned from the book, because it is so intertwined with my own experience and the stuff I write on this blog. However, to conclude, for me the book will function as a reference in the future, my feeling says it won’t become a ‘dust catcher’.
I’ve bought the book in January and I am still starting to read the 8th chapter! Like you, my days only have 24 hours…
It’s an interesting book. For MDSD practitioners like you and I, it gives us another perspective. Like you said it’s deeply intertwined with our current knowledge and most things and advice sound familiar. The practical examples are most valuable because they represent different experiences we didn’t have, and it’s there that we practitioners will benefit.
For newcomers, I think that the practical examples won’t help because they are densely packed with information. The introductory chapters are better to convince people to use DSM or MDSD. After playing a little bit with the concepts, then the examples chapters will make much more sense, IMHO.
What’s written in the book is in line with ABSE, so everything sounded familiar and logical to me. DSM and how it’s presented in the book, is the concept that is closer to ABSE.