Ripple Effect Often Unavoidable

Many kinds of changes are going to cause ripple-effects (multiple change points) regardless of how much abstraction or indirection is used in the design.

Schema changes should generally reflect changes in the domain rules or domain model. Such changes may indeed ripple throughout multiple applications. However, such changes are often inherent to domain changes and usually not paradigm-specific or methodology-specific.

Let's take the common example of an initial Client entity with one contact (address). If any application wishes to display contact information for a client, it uses that one contact. Later because the company is now targeting larger clients, it is decided that a second contact be added. There will be a "billing contact" and a "sales contact".

If RDBMS supported "view columns" (most don't unfortunately), then existing applications could reference one or the other without change. The view column(s) would simply keep the old column name, such as Contact_ID. Contact_ID could be an alias for either Bill_Contact_ID or Sales_Contact_ID.

(A consolation alternative to view columns is to leave Contact_ID in place, and have an Insert trigger populate it automatically with either billing contact or sales contact. A view table may provide something similar, but can result in naming conflicts.)

However, most likely each application that uses Client's Contact_ID column will have to be visited to see whether the sales contact or the billing contact is to be used on a case-by-case basis.

Such decisions are inherent to change in domain processes, and are not only seen in just RDBMS. The "interface" to client information has simply grown more complex to meet new needs. Whether that interface is a class, function, or database schema does not change nor hide that fact. More complexity often means more decisions have to be made by any model. There are only so many things that an interface or abstraction can hide.

We can perhaps apply this to a more mundane example: A coffee machine. The first version of such a machine might initially start making the coffee as soon as you put in your coins. However, a newer version may offer a choice of regular or large via two buttons. The interface is now more complex. The old interface (user behavior) cannot work anymore without having the new system make an arbitrary decision. A question must be answered that the old interface did not ask.

• Good choice. Will that be black or with cream? Sugar or Equal/Sweet-n-Low?

There is no single "proper" translation of the old interface to the new one. Either the system guesses, prompts, or aborts the transaction. In an interactive system, a prompt is generally the remedy. However, it may be a batch transaction in some cases. Your buddy may have asked you to pick up a cup of coffee for him/her, without knowing about the new size choice. Do you call him/her, guess, or abort? The polite thing to do is probably to select the large choice, but pay for the difference yourself if he/she wanted small. Of course, this does not work well at a large scale, which is something a computer may be dealing with.

If a change results in a ripple effect, ask yourself if it is an unavoidable change in the domain interface/model, or the result of a bad technical decision. If it is the second, then make a lesson out of it by understanding why the decision was made and if avoiding it is worth it or would have been PrematureAbstraction. We cannot foresee all future changes and so are going to get it wrong at least some of the time.