I'm going through the Patterns and Practices Application Architecture guidance. The first place I'll start is with the Architecture and Design Guidelines.
Let's start right at the top:
Software Architecture is often described as the organization or structure of a system, while the system represents a collection of components that accomplish a specific function or set of functions. In other words, architecture is focused on organizing components to support specific functionality. This organization of functionality is often referred to as grouping components into “areas of concern”. The following diagram represents a common application architecture with components grouped by different areas of concern.
I want to hone in here on the word "component." It's true that the architecture of many systems is composed of components, but is that really the best way to describe it?
Component-Based Development
Judging by the rest of the document, the word component here has a very specific meaning. This meaning comes largely from the practice of Component-Based Development. I don't want to go into specifics on this here, but I will point you to a couple resources for more information.
One of the key things to remember is that CBD guys see Components as an evolution of the Object. I'm not going to say their perspective is wrong. It's just important to realize that it's *different* from many of us still writing object-oriented systems. This includes everyone from Martin Fowler and the DDD crowd to the growing crowd behind Rocky Lhotka and his Business Objects.
The other thing to notice is that we don't have to agree on everything, but that the Component line nicely divides most developers that care about such things into one of the two camps.
Back to that Definition
So the question is, how do you address a topic such as architecture in a way that doesn't clearly identify with one of the two camps?
Luckily, this has already been done for us. Indeed, it not only works for both design camps, it works with all the others as well (such as the growing crowd of functional programmers).
From the book, Software Architecture in Practice:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
You'll notice we've swapped the word "component" for element. This covers us for all crowds: components, objects, and functions. In addition, we've introduced the notion of "externally visible properties" into our definition.
At first glace, this may look like black magic, but after deeper digging, we learn that the "externally visible properties" of the architecture are really its quality attributes: availability, modifiability, performance, security, scalability, testability, usability, etc.
While I don't expect a guidance document to fully describe the use of these attributes to design our architecture, exposing these properties of any type of example architecture does two things:
- It draws some type of line for where the architecture should not be used
- It gives markers for a developer reading the document to find his own way or look for reference material for additional clarification
P&P Recommendation: Reword this document so that it's less specific to components (as much of the content already is). If a sample component architecture is desired, move the component-specific stuff into it. Be careful of labeling component-based development with a guidance label (sans "sample"). Otherwise the community *will* use it as the defacto standard.
posted @ Monday, September 15, 2008 8:57 PM