The Architecture - Part 2
I am still bringing the story of Charlie up to date. At this point, it is the start of the new year. Before Charlie’s hiatus, I had created an elevator pitch, a feature set, a broad architecture, and a software specification. After Charlie’s hiatus, I had worked through Cuyahoga, and used that experience to determine the final elements of research that I needed to undertake before commencing Charlie. As you will see from the preceding book reviews, I researched both object-oriented programming and design patterns.
At the start of this year, I was ready to go. Because I am a visual thinker, I wanted to start with a picture. I fired up Photoshop and created the following diagram (you may click each diagram to see a larger version):
This simple diagram included four main things. First, it showed the users of Charlie. By users, I don’t mean Jim and Joe and Josephine. I mean a visitor, a member, a webmaster, a content author, a developer, and so on. Second, the diagram showed the devices used by the users, such as a web browser, a PDA, a speech synthesizer, and so on. Additionally, the diagram included a few devices without a user, such as an RSS aggregator and the Google spider. Third, it showed the external resources that Charlie would use, including databases, files, and web services. Finally, Charlie is shown as being a “black box” which accepts a request from a device, and sends a response back to the device. That is all Charlie does: accept web requests and provide web responses.
I then added the layers that I envisaged Charlie would need. The diagram now looked like this:
Starting from the bottom, the Foundation layer represents the underlying technology that I will not create, but upon which I will rely. The Foundation layer will be the .NET Framework (which comprises ASP.NET), but at this stage the diagram is meant to represent logical separations, not specific technologies.
The Services layer will be those components that provides services to the layers above. Services will include database access, graphics, logging, messaging, and so on. These components may be custom, may be open-source, or may be commercial.
The Persistence layer will provide the mechanism by which the business objects in the Business layer above can save and retrieve data from the external resources such as databases, files, and web services. In other words, the Persistence layer provides the “mapping” between the object-oriented stuff in the Business layer above, and the non-object-oriented stuff below. This means that the business objects will never know where their data is stored, and the external resources below will never know how their data is used. Charlie therefores provides a separation of concerns, which is the whole purpose of an architectural diagram.
The Business layer provides, well, the business objects. For anyone who does not know what a business object is, it is an programming object that represents a real-world thing. As Charlie’s purpose is to serve webpages to users, Charlie's business objects will include a User object (representing the real-world user) and a Webpage object (representing the real-world webpage). While that is a very limited view of what a business object is, it is a useful starting point to understand the purpose of a Business layer.
The Controller layer will provide the mechanism by which the business objects in the Business layer below can present themselves in the Interface layer above. If the Persistence layer provides the “mapping” between the business objects above and the external resources below, then the Controller layer provides the “mapping” between the business objects below and the interface above. Like the Persistence layer, it is a contrived layer that helps the business objects stay pure, to prevent data access or interface stuff from creeping into the business objects.
The Interface layer will provide the mechanism by which Charlie presents stuff to the user and interprets actions from the user (such as the user clicking a button or a hyperlink). Some books suggest that for web-based applications, a separate Presentation layer should be included. The Interface layer executes on the server, and the Presentation layer executes on the client. Because they are physically separate machines, they should be represented by logically separated layers. While true, I consider that the Devices shown in the diagram comprise the Presentation layer. Moveover, Charlie has no responsibility in the Presentation layer (it’s done what it can in the Interface layer), so to add the Presentation layer is just needless complexity. Say it with me now: simple is better than complicated.
The Runtime layer provides the mechanism by which Charlie starts running and then keeps running. This is the layer that accepts the incoming web request, assembles all of the components needed to handle that request, facilitates the interaction of these components, and ultimately sends a web response to the user. If the other layers are seen as the workers, this layer is the manager who tells everyone what to do, and when to do it.
In Scott Ambler’s five-layer architecture, he shows the System layer being placed to the side of the Persistence, Business, and Interface layers. Strictly speaking, my Services layer and the Foundation layer should “wrap” around the other layers. While that presentation would more accurately describe which layers can talk to which other layers, it makes the diagram more complex than it needs to be. So I have stayed with the simpler, stratified diagram.
With the layers finalized, I revisited my earlier architectural diagrams. The main thing I had determined from that earlier exercise was how a plugin module could provide interface, business, and data access elements. While the result might be comically obvious to a trained developer, this self-taught developer had to go through the thinking process needed to arrive at the obvious solution. So I added the modules to the new diagram. By this time, however, I had decided not to use the term module. That term already has a specific meaning in ASP.NET, so I decided to use Plugin instead. Here is the final diagram with the plugins added.
I printed a copy of the above diagram, had a laugh at how long it took me to arrive at such a simple architecture, and then pressed on.
by Alister Jones | Next up: The Simplicity of Casting →
----
Post a Comment