Application Architecture
In a recent project I’ve had to implement a feature I think is a good example of a separation of concerns at a small scale. This feature involves giving the user a choice from a set of items. The available items from which the user may select an option is determined by a couple of factors. First there is a pool from which they may draw items. Users will preferentially get only those items directly associated with themselves if any are available. If no items are associated with the user then they get those associated with their user class....
On my current project we’re building multiple websites that share the majority of their logic but each have requirements relevant only to their target audience. This means we need a way to configure the common elements to behave appropriately to each scenario. This post discusses the mechanism I’ve chosen to do this. In building this mechanism I had a number of goals: Minimal Duplication It was not acceptable to simply duplicate whatever logic needed to vary. Whatever mechanism I chose has to keep as much logic common as possible to constraint development cost and ensure...
Further to the discussion that Rhys Campbell and myself have been having regarding interfaces, Lee Campbell has stepped in with a discussion of interfaces primarily related to Unity. Well worth a read, and I like to think somewhat of a justification to go download StructureMap.
When implementing services there are a number of practices I like to adopt. I have already discussed the use of interfaces to define the service contract. This post is to discuss the granularity of the contracts in a system. In all but the most trivial of systems multiple service actions will be required. In providing these actions we can choose a position on a continuum. At one end we have a single contract that has all the actions as methods. At the other end we have a separate contract for each action. In between we have contracts that provide...
Strategy is a pattern that is often useful in encapsulating variations in logic. In working with a domain model there are often scenarios where it would be advantageous to be able to apply a strategy. There are a number of ways in which this may be achieved involving varying design tradeoffs. In making our selection there are a number of considerations that may be applicable: Dependency injection into domain objects is generally undesirable. They will often be managed by an ORM which would require us to integrate into the ORM in order to allow the...
When designing a system there is always the temptation to use the latest and greatest technologies. This is based on the (generally true) premise that new technologies are superior to older technologies. The implicit reasoning from here is that using a more advanced technology will result in a better solution. In practice however this does not always hold. As an example I recently purchased a second 24 inch monitor for my home system. I selected a Samsung 2493HM because it was the size and resolution I wanted and had decent reviews. One element of the reviews I do wish...
Consistency is a desirable property in a codebase due to the benefits in understandability and maintainability it provides. Application architecture assists here by providing a common template to which the system is constructed. Therefore the design of the architecture should be done in such a way that consistency may be effectively achieved. This does not mean that the benefits of consistency should imply that consistency must be enforced universally and in all cases. There are a number of cases where managed inconsistency brings greater benefit to the system. Some systems will have highly disparate elements where there is no...
In my previous discussion of patterns I touched on one of the most frequent anti-patterns; overuse of Singletons. Today I'm going to elaborate with an example of what happens when you use multiple anti-patterns together. As always details not relevant to the example have been changed to protect the guilty. The application in question was an existing code base which I was brought in to assist with. The system suffered badly from Singletonitis. Many of the items configured as Singletons had no state and had no business being Singletons at all. In particular the data access layer was invoked...
Design Patterns are a mechanism whereby design knowledge can be encapsulated, considered and applied in a commonly understood way. Patterns form the basis of a design grammar that allows architects to discuss the composition of the design in a clear and unambiguous fashion using common and well understood terminology. They also gather knowledge of design constructs in a format that allows them to be readily shared and applied in multiple contexts. Design patterns tend to have significantly better reusability than software components. This is because design patterns are abstract knowledge that may be applied, whereas software components have concrete implementation....
Jeremy Miller has written a good article on the Open/Closed Principal and friends for MSDN. Read it now. (NOW!)
The waterfall model provides a nice clear answer to the question of when you do the design. You do it up front, after you've done your requirements analysis and before you've done your implementation. This answer is simple, clear, and completely and utterly wrong. Project managers tend to like it because it's easy to put on a Gantt chart but the connection between this model and reality is tenuous at best. There are in my opinion two primary problems with attempting to do all your design up front, and these problems are interlinked. Firstly it ignores that design permeates all...
For my discussion of application architecture I'm creating an example application to demonstrate some of the concepts and tradeoffs involved. The problem I've chosen is an online movie review site based on the movie review strategy I've recently adopted. As the first step I'm going to define some requirements. Normally these are sourced from the business using requirements analysis. However in this case I'm just going to make them up. This means that they will be incomplete, inconsistent and wrong in places, which makes them indistinguishable from real requirements. In practice requirements tend to change over time due to shifting...
Build vs. Buy* is a question faced by any significant development effort. Existing third party systems are available for most business functions, such as finance, content management, portals, CRM and many others (I'm not going to discuss the pedantic cases of operating systems, web servers and the like). For these kinds of functions buy is almost always the better alternative. My plan is not to discuss what kind of criteria you should make this evaluation on. Rather I intend to discuss the effects of buying a third party system will have on your application architecture. For the purpose of this...
In order to achieve useful outcomes software must comprise a variety of behaviours. These behaviours can be grouped into particular areas of concern. In developing line of business applications (and generally across a number of application types) there are three common areas of concern; presentation, business logic and persistence. Presentation concerns the display of information to the end user and the handling of user input. Business logic is concerned with the handling of the business functionality for which the application is constructed. Persistence concerns the storage and retrieval of the data on which the application operates. Applications may have other...
In my previous post I discussed a variety of desirable attributes in an application architecture. I made the point that although you should make some basic concessions to performance (such as avoiding chatty communications) optimising for performance without being able to measure the results is generally sub-optimal. I made the point that in most cases "good enough" performance is generally all that's required, beyond which additional performance gains have no benefit. However, what about cases where this doesn't hold? How do we address problems where we need to be able to add additional performance to an application over time? What...
In discussing application architecture we need to start with an understanding of what we are looking for from the architecture. Architecture is additional work over and above simply writing code. We therefore need to understand the justification for doing it. Additionally if we wish to do it well we need to understand our goals for the architecture so that we can best meet them. All applications have at least an implicit architecture, even if this architecture can be best described as a "towering pile of hacks". Therefore we must consider what thinking about architecture explicitly gives us over this base...
There are few things that can guarantee failure of your project more successfully than a bad architecture. The truly insidious thing here is that you may not realise the scope of your problems until your first release is out and you're left with an instant legacy disaster that will be a nightmare to maintain and impossible to extend. Here are some semi-fallible warning signs that your architect may not be quite ready for the challenge of building your application. Your architect has never maintained a system before Maintenance of an application is a very different thing to building a new...
Architecture in software development tends to be one of those ambiguous terms that means many things to many people, and rarely the same thing to anyone. There are some things that are clearly architecture, some that are clearly not, and many that live in a grey world of ambiguity. In this respect it's much like service, the clear current leader for most ambiguous prevalent term in computing. Modern enterprises need architecture at the enterprise level in order to build IT systems that are effective and coherent across the entire scope of their business. This is high level architecture where you...