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.
No comments:
Post a Comment