How to sort out the problem of access to someone elses data?

Imagine an application built upon the below displayed architecture (it is a real-life example)

Is it obvious what the problem is? Who’s got trouble reading the ArchiMate notation will have to learn it swiftly. How about learning it from us, in Komix?

Whatever comes to your mind there is still one trouble. Any structural change made by the B-Team in “Table B-1” will manifest itself by breaking “View in Table B-1”. It means it has an immediate effect on the work of A-Team, regardless of the fact that the change in question is only an internal matter of the B-Team. It may not be apparent at first sight, but the fundamental principle, that one module should not access directly the data of another module, is broken. (Here, we understand a module in a broad sense as an application module including its DB schema).

How to fix the situation, ideally, without having to redesign the whole application from scratch? How about this way?

Are the benefits clear?

The A-Module uses the agreed upon interface (implemented as View) that is generated by the B-Module and the internal changes in Table B-1 can be stored by the B-Team by modifying the View accordingly. As a result, the A-Team is not effected by such changes and adherence to the principle of not accessing directly someone else’s data is respected.

Here we come with an even more sophisticated solution:

What did it bring to us?

This alternative preserved advantages of the above mentioned version, and above that, compared to the original version, there is no need to modify the A-Application Module. (The change will manifest itself only in the definition of View in the A-Module DB schema.) Furthermore, the principle that an Application Module should only access “its own” data is maintained. (In spite of the fact that, at the DB layer level, it is implemented by creating a Link to another schema.)

A lot more could be written on this subject, dealing with the pros and cons of the above mentioned kinds of solutions (and prospectively others) and their consequences. Here, the floor is yours… Hopefully, this brief article will serve you as a source of inspiration.