[ComponentDesignPatterns | CategoryPattern]

'''Context'''

You're developing in an environment where location of associated components can change in the course of a project.

Perhaps the location of a component can change at runtime.  It might be required to exist a on different platform if distributed, or a different protocol might be required to communicate with it.

Security and reliability issues differ depending on the location of your component.

You're ''not'' in an environment where your program works the same regardless of the distribution of the components and frameworks it is composed of.

'''Problem'''

How do you guard against the physical location of components affecting your system in unfavorable or unforseen ways?

'''Forces'''
	* Abstracting an application from the physical location of a component increases flexibility.
	* Making assumptions about the physical location of an object can come back and bite you.
	* Security, performance, and reliability issues arise if a component is distributed.

'''Solution'''

Explicitly recognize and decide upon the allowed location of components that depend on one another.  Classify components into ones that either can be distributed (domestic or foreign) or cannot be distributed (domestic only).

'''Resulting Context'''

Relative to a component, you might use AbstractInteractions with domestic components, and GoingThroughCustoms and developing InterfacesLast with foreign components.

FacadesAsDistributedComponents can be used to create a portal for an application to get authorization and authenticated to use server components.

'''Known Uses'''

'''Example'''

'''Related Patterns'''