I'm a freelancer consultant, and everytime i have to explain how to design & create code that runs fast, it is easy to maintain and that can support business requirements changes, i found myself talking for hours explaining why we should create Data Layers, why we should refactor our code, why we have to take care of database design and schema abstraction and so on.

Well, a few days ago i found a nice concept that can be useful to explain all this thing togher, hopefully even not only to technical people.

Here i'd like to share with you my idea, and get all the feedback you want to give me, so that i can better understand if it's so good as i'd like to think or not at all :-)

Here's the concept: "Contact Surfaces". When two systems (an application and another application, an application an a database system) needs to operate togheter, they needs to share some data. We can imagine all the data that needs to be shared as a "Surfaces of contact". All our efforts to produce and create a better code goes into direction of minimizing these surfaces.This because these surfaces produces friction. The bigger they are the higher will be the friction. Friction can be though as the performance drop you have when you must adapt these surfaces to your new business requirements (and so, for example, make them work with another new surface).

With this concept i'm able to explain why a Data Access Layer is so important, or why a loosely coupled system should always be preferred.

I'd like to have yout opinion on this concept. Does it suits well?
Or I am missing something?