Why Class Based Domain Modeling Does Not Work

Sean Mcgrath shares his opinion on what's really wrong with using Classes to model reality. He writes:

The classical approach to data modelling - as enshrined in techniques such as data dictionaries, object models and XML schemas - is to model the data rigorously from the top down. Every thing in the model has a name. Each thing is either a simple lump of data or a complex thing. Complex things, themselves have names and models. And so it goes.
...
The trouble is, this modelling exercise never ends. The essence of an invoice refuses to be modelled. Every model, to paraphrase Oscar Wilde, becomes a work of art that is never finished, simply abandoned. If this were not the case then surely we would have a definitive invoice model by now? How come our planet is so chockablock with mutually incompatible, application-specific models of invoices? How comes new ones appear every second day?

My fuzzy memory recalls that I wrote something about the inherent problems with class based modeling in "Is it high time to get rid of classes?". There are other inherent weaknesses of classes, however when it comes to modeling the multiple viewpoints problem or its related problem "the tyranny of dominant decomposition" is most obvious. Questioning the effeciveness of class modeling or similarly using grammar based schemas has been surfacing all over the place. "What if we just get rid of schemas?" mentions but a few other authors who have been questioning their underpinnings.

Rather than whine about it, Sean takes a stab at a solution:

The important thing is that you never actually decide that it is definitely an invoice, rather, you decide that it is more like an invoice than any other document type you know.  Invoice-ness is statistical, fuzzy, fluid. It is not solid, not deterministic.

Sean uses the term 'duck typing' that is if it walks like a duck, quacks like a duck then definitely must be a duck. I've usually called "pattern matching", this idea is a weaker form of what Lanier coins Phenotropic computing . It's also something I recognized earlier as a form of of loose coupling and an alternative to schemas,

However, the troublesome aspect of all of this is that the majority of proponents inside standardization bodies seem unwilling to recognize that this is more than "a nice to have", it is a fundamentally problem that Sean expounds on:

The standard approach to data modelling would seem to be antithetical to flexibility. The answer to this conundrum is not yet on the horizon. Indeed, recognition of the problem is not yet widespread in the industry in my experience. We hear lots of nice words like 'flexibility' and 'loose coupling' but they tend to have vague, abstract definitions.

Yes, "loosely coupling" is a bit vague for many, however I hope my taxonomy clears up the waters.