Thanks to everyone who came out to the event last weekend. Please find attached my slides for my presentation on modeling software architectures and some corresponding code.

Modeling Software Architectures

Bug Tracker Code

Thank you to everyone who came to the meeting to hear about Pragmatic Architecture!  Please find my code below. 

You can download the original code here: Original Shopping Cart Code

My converted C# Code

My refactored C# Code

Please feel free to contact me with your comments and suggestions!

Thank you to everyone who came to the meeting to hear about Pragmatic Architecture!  Please find my code below. 

You can download the original code here: Original Shopping Cart Code

My converted C# Code

My refactored C# Code

More refactoring is left as an exercise for the reader  =]

Hint: use a strategy pattern and remove the dependency on the HttpContext and SortedList.  Enjoy!

I was in a meeting with the AppVenture development team, and we sought to answer this question so that we could build a tool to help software architects design and communicate architectures. 

We needed to define architecture so that we could determine what needed to be communicated.  So using Single Responsibility and the Separation of Concerns principles as our guide for architectural layers, we defined architecture as all the software layers and the way those layers interact in terms of dependencies.  One interesting finding is that our notion of architecture uses a composite pattern. 

This leaves us with a simple conceptual model:

Figure 1. The conceptual model for architecture.

Using this simple conceptual model as our guide, we could create this simple architecture:

Figure 2. The AppVenture Simple Architecture (ASA)

Let's call this architecture the AppVenture Simple Architecture (ASA). So in this architecture, we have three architectural layers (this is probably the simplest architecture I can think of): a UI architectural layer, a Domain architectural layer, and a Repository architectural layer.  In the ASA, the UI layer would probably have a sub-architecture (which is of type Architecture) that has a different manifestation for each UI technology.  This UI sub-architecture would have another model that could resemble this for an ASP.NET Web Application:

Figure 3. The UI sub-architecture for an ASP.NET Web Application.

In this instance, the UI Architectural Layer has a sub-architecture (shown in Figure 3) that contains three architectural layers: a Master Page architecture layer, an Aspx Page architectural layer, and an Ascx User Control architectural layer.  One interesting thing to note here is that in Figure 3, the Ascx User Control architectural layer depends on the Domain architectural layer from the ASA architecture (Figure 2).  That dependency exists in these models to illustrate that in this architecture, the Aspx pages do not contain any dependencies to the Domain.  What this design decision means is that Aspx pages are simply containers for Ascx user controls.

I would love to hear your thoughts on this model and see which architectures do _not_ fit into this model.