When expectations are high, you’re invariably up for some disappointment. Charles and Tom were unable to demo Rails-in-a-war-on-Glassfish; but at least they gave a warning in advance. But I definitely expected something more–or rather something else–from Eric Evans’ university session on domain-driven design (ddd).

The afternoon session on scripting languages went well enough anyway–or at least, the JRuby part did. The session took off with a theoretical explanation of JSR-2something (the support for scripting languages in Java SE). After that, Charles and Tom got their chance to warm up the Java-minded public for all goodness of Ruby. It took a little while for them to get comfortable, but then Tom was at the keyboard showing the simplicity of building a small Rails app from scratch; and Charles got the flow of the presentation going, explaining what Tom was doing and going into JRuby details. The hour flew by for most of the audience. When I got back after the half our break, Charles and Tom were still answering questions.

Charles and Tom showing some well-known faces

Now you have to believe me, in the 90 minutes of Groovy that followed, I did keep an open mind. I tried to look at the code samples objectively. I tried to admire the work that has gone into creating a dynamic variant of Java. I really tried hard to imagine a scenario where I would be tempted to remotely consider using Groovy in a real-world app. Okay, and I was also just a little bit busy trying to get my laptop to talk to the JavaPolis wireless network, which wasn’t easy either. But at least that one I finally succeeded at. The Groovy thing–I’m afraid it’s not for me. It gives me the worst of both worlds: no sweet Ruby syntax, and on top of that uglified Java syntax as well. Maybe next time I’ll see the light. I promise to keep an open mind.

The thing that most disappointed me however, was Eric Evans’ morning session on domain-driven design. Not that it was a bad presentation, not at all. Maybe it’s all about expectations. I expected an introduction into ddd. What is it, what’s so great about it, why should we use it, what lessons have been learned, what tips can a ddd guru give us? Instead we got a session about domain modeling: how do we get from use case to domain model. And also, if we have multiple models within our application/organization, what patterns can we discern regarding the interfacing between those models and the teams that design them? Interesting enough, no problem there; but what does this have to do with ddd? Domain modeling like this can well be done without any domain-drivenness. Or can it? I’ll know more in a week or two, when Evans’ book that I ordered will arrive.