Patterns for building Utility Data Models

Patterns: A Methodology for Design
A methodology for capturing problems and articulating design solutions has emerged - first within the discipline of architecture and more recently in object-oriented software development.

Christopher Alexander first elucidated the notion of patterns and pattern languages to capture elements of architectural design. He has written several books including A Pattern Language.” Towns, Buildings, Construction and The Timeless Way of Building. His insight was to identify as patterns those qualities that make living spaces more attractive and then to combine those patterns into a framework for designing buildings and communities. His writing asserts the dominant goal of architecture -to enhance the human condition by designing living spaces that promote qualities such as openness, freedom, accessibility, and comfort.

The application of a pattern methodology towards software design became widespread with the publication of a seminal book, Design Patterns: Elements of Reusable Object-Oriented Sof~are, by Gamma, Helm, Johnson and Vlissides. These authors borrowed ideas from Alexander and compiled a catalog with definitions of core software patterns frequently encountered such as iterator, proxy, composite, factory method, singleton, and fayade. Design patterns are low-level archetypes that are broadly applicable to all facets of object-oriented software development. Patterns are also being applied as higher levels of abstraction, such as data objects in a application.

Elements of patterns
Christopher Alexander says this about patterns: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without every doing it the same way twice.” This description is also apt for software design. Designers immediately recognize a good pattern as ubiquitous and useful.

A pattern is documented as a structured narration of a design solution. Patterns are being used in a wide set of domains, so the elements and format of this structured narration vary, but most practitioners recognize these elements of a pattern:

A name is an important attribute of a pattern which succinctly describes it, is universal to the range of applicable domains, and can be naturally used in conversation.
Each pattern exists within a context that describes the problem to resolve and the forces at play. The context dictates whether a given pattern is applicable or useful.
The solution describes the parts of the design that cleanly resolve the contradictions among the forces upon the pattern. The solution is not a technical specification or pseudo-code; it is a conceptual description that reveals insight.
The application of a pattern has consequences that are declared. These consequences are side-effects of the solution and the trade-offs made in the design.

The goal of patterns is to enable the communication of insight and sharing of experience among people working in related fields. A data modeler analyzing the components of a telecommunications system can share essentials of design solutions with a peer working in electric utility or water utility domains.