Background
This question stems out of an architectural discussion we had at work.
For the current project we are using Python and an object oriented database. There are input services that we consume, and certain interfaces that we are expected to provide output through.
Someone on our team started designing a data model, and my question was: why?
A data-only object in Python can just as well be be represented by a dict (there is a fair amount of questions about that on this site). We don't have a relational database that has columns that we need to map objects to either. At the same time, there is a cost to a data model in that it will always need to be maintained. When interfaces change it (IMHO) simply becomes another dependency that needs to be satisfied, but unlike in static-typed languages it does not actually enforce anything.
Question:
The way it seems to me is that when you are in an environment where everything is dynamic, it makes sense for the interfaces to define your data model implicitly rather than maintain some sort of classes that define a model. Are there ever any good reasons to the contrary?
EDIT
In the comments and answers people seem to be focusing on two areas, they are: database mapping and representation as well as validation of the data model.
I apologize for not being more explicit about the DB, but in this environment that we face we have an object-oriented DB that stores blobs in a file system-like representation. There is no mapping to SQL and no ORM of any sort to speak of. I do understand the argument though. For example, Django's models require subclassing for ORM to work. In thise case, making model classes makes perfect sense because the DB is effectively a static-typed data store and not 'dynamic'. But this is not the scenario of the question, because it's not a pure dynamically typed environment.
Regarding validators: yes. One will need to create validators that check fields being present, and them being of the right type. In static-typed languages the model implicitly does this (when you're coding C++/Java you can't stick user 'std::string' to where a User class should be). But in Python, a model class does not enforce anything. If I am building validators that check presence of attributes anyway, does this not make classes, dicts, generators etc functionally interchangable? And if so, should the solution not be one with least code? Validators in general seem to me to be an argument in favour of not building data model classes rather than the contrary. Am I wrong in this?
Best Answer
Even in a dynamic language the principles of Domain Driven Design can still apply. If all you're doing is passing around dictionaries, you have an Anemic model where your objects are pure data and other objects operate on them.
Taking the time to create a rich object model and embedding logic into the model provides an opportunity for your model to be more expressive and representative of the domain you're modeling.