My approach is to start out as simple as possible, because you know
everything will get more and more complex as time goes on.
On 8/10/2015 8:10 AM, Costello, Roger L. wrote:
> Hi Folks,
>
> Below is a slight twist on something that Eric Raymond wrote [1]. I
> welcome your thoughts on this topic. What schemas have you seen that
> have excessive layering? /Roger
>
> XML Schema make abstraction easy — perhaps too easy. It encourage data
> architectures with thick glue and elaborate layers. This can be good
> when the problem domain is truly complex and demands a lot of
> abstraction, but it can backfire badly if schema designers end up doing
> simple things in complex ways just because they can.
>
> Too many layers destroy transparency: It becomes too difficult to see
> down through them and mentally model what the data design is actually
> doing. The Rules of Simplicity, Clarity, and Transparency get violated
> wholesale, and the result is a data design full of obscure bugs and
> continuing maintenance problems.
>
> This tendency is probably exacerbated because a lot of educational
> courses teach thick layering as a way to satisfy the Rule of
> Representation. In this view, having lots of abstract types is equated
> with embedding knowledge in your data. The problem with this is that too
> often, the ‘smart data’ in the glue layers is not actually about any
> natural entity in whatever the schema is representing — it's just about
> being glue. (One sure sign of this is a proliferation of abstract
> subclasses or ‘mixins’.)
>
> [1] http://www.catb.org/esr/writings/taoup/html/unix_and_oo.html
>
