Structure Preserving Transformations
Now that you have a general idea of what Christopher Alexander's Theory of Centers is about, it's time to delve a little deeper into the 15 properties that define "living" structure.
The interesting thing about these properties is that they are also dynamic evolutions - Christopher calls them Structure Preserving Transformations, and they can be defined like this:
A Structure Preserving Transformation is an evolution that improves the overall structure of a system of centers.
These transformations usually perform one or several of these evolutions:
- adding new centers that reinforce existing ones
- removing weak centers that just add "noise" to the whole structure, or weaken stronger centers around them
- reinforcing existing centers by grouping them into a larger, stronger center
My goal here is to give you an overview of these transformations in the realm of software. But before going further, there are a few points that need clarifying.
More than refactorings
"Structure Preserving Transformations", that sounds a lot like mere refactorings.
The truth is, they are refactorings. They are a means for improving the structure of a piece of software without changing its behaviour.
The reason why I don't call them refactorings is that I don't want them to be confused with the refactorings found in Martin Fowler's "Refactoring" book. These refactorings - Rename Variable, Extract Method, Inline Method, etc. - are usually low level evolutions that are not necessarily good or bad by themselves. They are code manipulation tools rather than design guidelines.
By contrast, you probably want to use most of the Structure Preserving Transformations in your design, because you want it to exhibit the corresponding static properties over time. These transformations will help you fight entropy and preserve - even improve - the structure of your application during its growth.
Let's suppose you are working on a less-than-perfectly-designed application. You can see these transformations as 15 tools at your disposal in your toolbox to start improving its internal structure. Once you start getting comfortable with these tools, you'll be probably saying things like "let's increase the contrast between these two modules", or "this area lacks a clear boundary".
A new way of organizing design knowledge
Note that the underlying design principles that I describe here are not really new by themselves. If you are already comfortable with software design, you'll probably know most of them - Separation of Concerns, Don't Repeat Yourself (DRY), etc. You can find more or less the same ideas in the Design Patterns, or in Robert Martin's OO Principles (Open Closed Principle, Liskov Substitution Principle, etc.)
What is interesting here is combining all these principles in such a way that we get a new vision of how an application is structured, and how it should evolve over time.
Transformations index
Note: In what follows, I use the term "module" quite loosely - it could be a whole application, a library, a class, or even a function. Remember: all these things are centers, they just happen to live at different levels of scale.
Here is the list of these transformations:
| Contrast | Fight entropy by creating areas with specific responsibilities, as different as possible from other areas in the application. Make then sure that they remain different over time. |
| Levels of Scale | Organize large modules into a hierarchy of submodules. At any level of scale, break down modules as soon as they grow too large. |
| Boundaries | Introduce interfaces between modules so that you can work inside a module without "seeing" the whole application, and so that the module can be used as a black box in other modules. |
| Gradients | Introduce gradients of privacy to help people find their way into the application, and gradients of stability to make the application less brittle. |
| Alternating Repetition | Organize similar modules in the same fashion, to give a feeling of repetition of a same structure across these modules. |
| Local Symmetries | Align similar modules by bringing them under a single interface. This interface becomes their axis of symmetry. |
| Echoes | Some concepts will have different representations in different parts of the application (for instance a Contract will appear in different forms at the UI, model and database levels). Reinforce the similarity of these various representations so that they echo each other. |
| Strong centers | Organize the centers of the structure around a few strong centers - for instance the main window of your application, or the main concepts of the business domain. These centers act as starting points for the exploration of the software, and they get reinforced by centers around or inside them. |
| Positive Space | Take care of what is left "outside" your application so that it exhibits a good structure too. This involves for instance making sure that import/export functions are properly done and allow a good level of integration with other systems. It can also mean having well-defined interfaces allowing people to add plugins to your application. |
| Simplicity and Inner Calm | Remove as many weak centers as possible so that the remaining structure appears simple and straightforward. Seek the corresponding feeling of "inner calm" when refactoring a complex piece of software. |
| Not Separateness | Integrate the software into its surroundings so that if feels part of the whole system. Give the same "look & feel" to modules across the application. |
| Roughness | Don't look for perfection everywhere. Acknowledge that the business domains we tackle are usually far from perfect clockworks, and that the project takes place in a far from perfect setting. Sometimes it's better to leave a small piece of the application that does not look "clean" rather than build a large and complex solution to maintain its "conceptual purity". |
At the time of this writing, there are three transformations for which I find no clear equivalent in software: Deep interlock & ambiguity, Good Shape, and The Void.
In subsequent posts, I will detail the first 12 transformation in turn, trying to establish a better understanding of the whole system. There's work ahead!
