Music is a highly structured art form… usually. This structure makes use of repetition and variation of form. Music can be monophonic or polyphonic, one voice or many voices interacting with each other. That’s what makes it interesting as a way of exploring code structure.
A Symphony is a collection of songs, called movements, connected in some manner. They share a collection of themes and other musical ideas. But each song operates in its own reality. Each song has its own musical key, tempo, and time signature giving each movement a very different feel. Each song still serves to bolster the Symphony as a whole.
Some applications have such different responsibilities we express each responsibility as a different executable program. A time sheet software may have a time entry client, a time entry server, time code management, a reporting system, and a payroll system. The themes that string everything together are the Ubiquitous Language and shared data interfaces. Each program has a shared understanding, but can act on that understanding in the manner that best fits its unique responsibilities to the application as a whole. In addition, some programs/services may serve to alter the data from one format to another, such as waiting until generating invoices to transform from a format used by most of the application to the format needed by our third party software.
Your basic pop song has an internal structure called Verse-Chorus form. The verses have similarities to their internal structure but vary differently in the content. The variance is usually the words of the verse. The chorus is the same, used to break up the verses.
We can see Verse-Chorus form in an app with several data screens, like the time entry client. Each screen is a Verse stitched together with both a data layer and navigation framework, the Chorus.
On occasion, a song has a radical change called the Bridge. This can alter the musical key as well as rhythmic underpinnings and has little similarity to the rest of the Verse-Chorus form but serves to add interest before returning to the original structure. As our time client grows, we find reports and off-line syncing that are important to our application, but are structurally very different from itself.
A Canon is a way of manipulating a melody. The simplest example would be Row Row Row Your Boat, where the melody is time shifted by one third. When this happens twice, for a total of three instances, we get a special class of canon called a Round and can repeat the layered melody Ad infinitum.
In our time application, we can think of the canon as the series of transformations we need to apply to our employees’ time data this billing period. We collect, group, transform, and collect again. In C# this can be a rather long list of Linq operations. In SQL, a very complex query. But a lot of the data accumulation and transformation can be carefully done in parallel. Much like a canon.
This is an incomplete metaphor. I wouldn’t use it as a means of laying out your code base. Instead, I can see it used to seed discussion about similarities and structure. By understanding that parts of your application have similarities and differences, the hope is we can group our code in a way that helps separate responsibilities, give clarity, and let developers quickly find the code they need.