Pragmatic MDD: Use the model, Luke

So (hopefully) we have decided about our stack: JSON for model definitions, CoffeeScript to do the magic and Node.js to make the magic happen.

But there is one tiny problem: unfortunately we are kind of misusing JSON here. In comparison to UML, we are gaining flexibility (a lot of flexibility), but also gaining verbosity. And I don't think we can do much about it.

We could, of course, like mentioned last time, go for the domain specific languages, but it would complicate things a lot, really a lot. So before going this way, let's give JSON a chance, embrace the ugliness and see, how far it can take us.

Ok, by now you are probably fed up with all these theoretical discussions and want to see some code, right?

Sorry, not so fast. First we need to decide what do we actually implement here, what domain do we model.

Since I'm a very lazy person, I don't want to come up with some fake use case on my own, but will just steal something already existing from the internet: It's a library model

Very original, isn't it? So we have some classes here, some attributes there... A few associations... One enum... I hope, you are as excited as I am...

But, ok, let's quit complaining, take for a start just 2 classes, Book and Author, and model them in JSON.

So here comes our definition. Like promised, it's quite ugly.

By the way, if you are wondering, why do we need to keep associations outside of class definitions, here is why: If we keep them inside the classes (meaning, one end of the association is defined in Book class, another end in Author), we could never be sure, that these 2 ends actually belong to the same association. For example, you could have multiple associations between the same pair of classes (e.g. for Book "writtenBy" and "ownedBy" and for Author "owns" and "wrote") and not know, what is the other end for "wrote". Is it "writtenBy"? Is it "ownedBy"? I hope, you can see the problem.

But don't let me hold you back, feel free to experiment with different ways of model definition. Everything depends on your use case anyway. For example, if you just want to generate POJOs/POCOs, then associations need to be placed inside the classes one way or another. Or to save some typing, you could put name and type of an attribute together, something like "string ISBN". Or encode the type in the name of an attribute like "sISNB" and "iNumberOfPages". Once I actually worked in a company with such coding conventions.

But let's move on.

Now we have our tiny model, so what's next? Let's generate some POJOs out of it!

I know, I know, isn't it kind of stupid to ask from all these hip JavaScript people to go down to the enterprise hell known as JEE? Or to expect from all these poor souls who are already burning in the flames of JBoss, WebLogic and WebSphere to have ever heard anything about CoffeeScript? For whom am I actually writing this? The most honest answer is: No idea.

Of course, we could generate JavaScript domain objects, but I'm just much more familiar with the daily needs (and pains) in life of a Java/C# developer, than a JavaScript one. Anyway, the generated code is just the result, it doesn't really matter for the purpose of this whole undertaking: Defining (or at least trying to define) a set of best practices for a pragmatic MDD approach.

But let's get back to business.

So we have our model now. It's ugly, but it's in place, this is already good news. What do we do next?

Let's think for a second: We want to generate code out of the model, so we need to define text templates for our code somewhere. Good. By the way, this is called with a fancy word "model to text transformation". But wait, wouldn't it be much more convenient for us from the template definition point of view to have all the information about a class in one place? You know, like "this class has these attributes and these associations". Because right now they are separated (for a reason, as described before). It's not so good for this particular transformation...

But we can fix this: before dumping our model into the text files, there should be an additional step, where we copy data that is needed and in the way it is needed from the original model into an intermediary one. This is called "model to model transformation". It reminds me a lot of the role that query is playing in CQRS: we are just defining a new view on the existing data in such a way that is most convenient for what we want to do with this data in the next step.

Congratulations, this is already all the theory you need to know, in just two paragraphs! This was not so bad, wasn't it?

But enough of the theory, let's take a look at the real code next time.

Pragmatic MDD: Choose your weapons

So where do we want to start? What technology shall we use?

Let's decide about the model definition first. When you take a look around and see all the tools out there, you will notice, that 99% of them are from "Draw me some UML" kind. This is not bad - visualization is a magnificent thing, but this approach has some downsides.

First of all, you are limited in your options, since you are writing UML and UML only. Do you need something else? Nobody cares, just go and write some more UML.

Let me give you some examples, how the world could look like.

How about enriching your model with some other data? There might be a domain architect who is designing his business domain and absolutely doesn't care about anything else. He doesn't want to pollute his model with some annotations. Is it an embeddable entity? Is it a single table inheritance? Is the primary key on the table surrogate or natural? Or actually why should he care about any non-business related id at all?

Or how about defining your test data for different environments and scenarios? For example we might have a non-functional test setup to check some performance metrics. We could define a data setup (something like "5000 users, 1000 products", only the stuff we really need for the test) and not care about the rest - about all these mandatory fields, all these missing references, persistence of the data...

And what about business validations? Wouldn't it be nice to define them in some language specific to our domain? And then let the validations be part of our code, always executed, never forgotten, design by contract style?

I guess, you already know where I want to go with this - domain specific languages. But let's leave this idea for now and come back to it some happy day in the future, let's start with something much much simpler...

So how do we define our model if it's not UML? What is the most popular data format nowadays? It's JSON.

It also has a wonderful property of being supported by almost every programming language you choose, but by one in particular it is supported so good, that I just couldn't resist: JavaScript. But why stop at JavaScript, why not take its smaller brother instead: CoffeeScript. With it you can write the same code, but just in a much shorter way. And since I'm a very slow typer I consider it being a big plus.

But wait a second, wouldn't we need to generate files or something of that kind? Isn't JavaScript (or CoffeeScript, which is just compiled to JavaScript at the end of the day) executed in sandbox in the browser so we can't write files? You are right, of course, but Node.js comes to our rescue - it will play the role of an execution engine for us.

By the way, if you have never heard of Node.js, hate JavaScript or prefer XML (I heard, such people still exist..) - no problem, feel free to create your own stack! But if you like my choice, but just have no idea about e.g. Node.js or CoffeeScript - no worries, the code we write will be just sooooo simple. It practically can't get any simpler than that, trust me.

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

.