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.