Software system construction often requires us to bring many varied and unrelated concepts together: a distributed financial MIS system brings together such diverse concepts as trading instruments, assets, transactions (both in the financial sense and the grouping-together-system-operations-into-a-single-unit sense), meta-data, database technology, network communication protocols, GUI, ... the list goes on. In the face of the pressure to produce a performant system quickly it may be tempting to tie these concepts closely together and so embed transaction-control code in the GUI code or network communication code in the business code. This leads to a system that is:

	* '''Hard to change:''' if you want to change the transaction-control system you need to scour all the GUI code to find all transaction-control related stuff
	* '''Hard to understand:''' busines code and network communication code are, in their own right, complex and hard to understand. Mix them together and the complexity multiplies before your very eyes.
	* '''Hard to write:''' if you're writing business code the last thing you want to be worrying about is catching network communication exceptions.

''Therefore...''

Write a layer of software to isolates two disparate concepts or technologies. This layer should isolate at the conceptual level (perhaps business code really needs to know nothing about networks or transactions - this is all handled transparently by some object management code) and/or at the technical level (handling unhandled exceptions raised by the object management code so they don't find their way into the business code). Isolation should be two-way (the business code 'knows' nothing of the communication code and vice-versa).

This leads to a system that is:

	* '''Easier to change:''' by isolating the database from the communication code we can change one or the other with minimum impact	
	* '''Easier to understand:''' each 'bit' of the system deals with only one concept: business, networks, database
	* '''Easier to write:''' business people can write business code that isn't polluted with code to display dialogue boxes or handle network exceptions.

Of course the IsolationLayer itself may well be very complex and, possibly, represents a single point of failure. Over-application of the pattern leads to a system where everything is strongly decoupled and so the effects of system events may be unpredictable and design or change is always 'selfish': distribution is hidden from the business designer and so they design without any thought for distribution - something which could bring the system to its knees.

'''An example'''

We have two isolation layers in our system. The first is the System Interface (SI) - the external interface to the system with which all clients (including our own UI) must communicate. The SI's responsibilities include log-on security, data validation, client-side caching (the SI is split across client and server), and handling unhandled exceptions. At the conceptual level the SI isolates the system internals from the 'outside world'. In order to connect to the system an external client must use the SI and so we can control the aspects of the system the client can interact with. Data validation ensures that all data passed from client to server (and vice-versa) is legal which means all server-side code can be written without constant checks for the legality of data values. Otherwise unhandled exceptions are caught and dealt with here so the client doesn't need to contain any exception-handling code.

The second IsolationLayer is the Object Management (OM) layer. the OM sits between the business code and the database. From the business code's point-of-view the OM hides details of distributed transactions (although the business code still needs to be transaction-aware) and communication protocols. It also hides how objects are created and accessed in the database and deals with any deadlock errors from the database. From the database's POV, the OM prevents deadlock from happening due to the business code by controlling the distributed transactions - hence deadlock errors are less likely to occur.

----

The subject of a subject-view pattern can be wrapped around a variety of application specific data, while GUI specific code can be isolated to the view side.  ObserverObservable has the same effect, without specifying what the boundary will be used to keep separate.
-- ScottJohnston

----

This idea, and use of MockObject''''s at the isolation layer, can contribute to successful UnitTestIsolation.

----
See also FaultIsolation