How to sort out the problem of access to someone elses data?
4. 5. 2022
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.
Manage Cookie Consent
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.