>I mean, domain (= middle) layer and database have a much stronger
>dependency than for example a userinterface and domain layer.
In the face of this dependency, I'm a little confused as to what the middle
layer does. If for example, it simply automates SQL queries and relieves
the user of the labor of writing SQL him/herself, then it certainly doesn't
contribute to interoperability. If on the other hand, it permits full
interoperability, then I'm not sure where the dependency comes in.
>OODBMS are even implemented within the domain layer. They just store
>the objects used by the domain layer as they are - as objects.
But, to the extent that OODBMS are implemented in the domain layer, they
aren't middleware and don't promote interoperability, right?
>RDBMS exist outside the domain layer but their goal to store the data of
>the domain layer makes them dependent on the domain object structure.
Did E. F. Codd say that? I would rather say that they depend on the domain
itself.
>It wouldn't make sense if some people created an OO model with objects
>having certain attributes and you created your tables which represented
>completely different entities=objects with attributes spread all differently.
But neither of those would be middleware.
The point I'm trying to make is that I have absolutely no gripe against
modeling the domain with just about any tool one can get one's hands on
(there are many commercial products that just use flat files), but if one
starts to talk about interoperability, one has to have a layer that can
talk to *any* model of the domain, I would think. Otherwise, don't call it
middleware and simply use it directly to model the domain.
John
