Pragmatic MDD: Introduction

Model driven development is incredibly useful. You actually have a model of your domain. You have a common language the business and IT can speak. Your developers can get rid of some of their monkey work writing boilerplate code. The changes in your model are propagated to all levels of the application architecture - front end, middle tier, database, documentation. You can be sure, that the generated code doesn't have bugs. But even if it has, you have to change it only in one place. The problem is, that there is also a price to pay for all of that.

Model driven development is hard. Or it actually can be easy, everything depends on your requirements. If you just want to have some fancy UML diagrams and generate POJOs/POCOs out of them, then you are in luck, this can be done quite easily. But what if you go one step further? What if, for example, you want to generate a DDL file to map your entities to the database using some ORM? Then you might still be fine with some out-of-the-box tool.

But let's make it a little bit more complicated: how about implementation of different inheritance strategies on the databaselevel? Or support of the business rules (which is a huge topic in itself, of course)? Or to have auto-update of the bidirectional associations between classes? Or something out of a completely different area - how about making it work and maintainable by more than one guy who has spent some years digging into this topic before?

Check out this list. How many modeling tools are already out there? And how many of them are not being developed anymore? The problem with out-of-the-box modeling software is that it can be of only 2 kinds:

• It is simple, easily understandable and - as a result - covers only the standard cases (unfortunately it is only a matter of time until you will have to implement a non-standard one and notice, that the chosen tool is not supporting it, but by that time you are already stuck with it)
• It supports all the transformations and templates you can only think of, all the formats and languages, but is so incredibly complex, that you will spend a lot of time building a working workflow for the current use case and you also will become the only one who can ever understand what you have built.

As I see it, the problem lies in variety of use cases itself - there are just so many of them and each one is a little bit different. So I want to try to go another way - to not build something that other people can use, but to show how simple it is for you to build something for your current use case by yourself - without using any of the fancy tools, but just a few helpful Javascript libraries (you don't have to use them by the way) any software engineer can easily understand.

I don't know what the result of this try-and-error project will be, but I am interested enough in its outcome to spend some time on it and see where it goes. I hope, you are too

.