This post might sound quite stupid, but I guess this is nothing new… There's been a long debate going on between two parties: those who prefer modeling a system starting from an Object Oriented domain model, and those who prefer starting from a Data Model. I am not talking about legacy systems where this choice is somehow context-driven, I am talking about the rosy scenario: just starting from scratch. My personal style is to never-ever start modeling from the data. I did it, when I was younger, and was developing a MSAccess VBA application. But that's it. In a OO system an Object is a richer entity than a Table: there's behavior that comes into play and I think that the table is sort of a projection of the domain model. To be completely honest, I have to admit that I am far more familiar with UML and Java than with ER diagrams or SQL, but that's not the main reason for me to do that.
I started to suspect that there is something more deeply rooted here. Ok, we can't really classify UML or ER modeling as a "primal instinct" – although some graffitis might be classified as "Cro-Magnon UML profile" – but peers tend to choose one way or another one "by heart" unless when constrained by the tools in use. Getting to a precise, DDD-like, domain model is a complex task, which involves a deep understanding of the real domain, that can be achieved through empathic discussions with domain experts and users. The goal is to understand a different culture, and the way is to respect it. Doesn't it sound a little bit like "make love not war"? From the data-driven guys point of view, this sounds a lot like "he had a difficult childhood" or "we've got to consider the environment he's been growing in" which results in a big loss of time. The domain is just another word for the data model, which is made up by data and constraints, all the rest is "OO-hippy stuff".
I assure you I was sober, when I thought this. I still think this is fairly stupid, but it fits a lot of my collegues… ;-)
No comments:
Post a Comment