Overview of the Cairngorm Architecture

Cairngorm provides a reference architecture for Flex applications that is designed to keep things simple and testable. It describes a way of structuring large applications out of smaller units.

A Cairngorm application consists of:

• Architectural Layers that separate classes with different kinds of responsibility
• Functional Areas that group classes related to the same area of functionality
• Design Patterns that coordinate objects in consistent ways

Architectural Layers

Classes with different kinds of responsibility belong to different layers than can be changed separately from one another. So if the visual design needs to be tweaked, most changes are confined to the classes in a presentation layer, and not other parts of the code.

Cairngorm recommends the layers described by Eric Evans in Domain-Driven Design:

• Presentation - presents data to the user and gathers input. i.e. the fancy UI
• Application - performs the operations of the application. i.e. saving a form
• Domain - models the business concerns of the application. i.e. the form data
• Infrastructure - coordinates objects and integrates with other systems. i.e. talking to the server

The figure below shows that code in a higher layer makes direct use of code below it. In the other direction, interactions happen indirectly through event listeners, callback functions and other means.

Continue reading to learn about the relationship between architectural layers, functional areas and design patterns. Later on, you can refer to the detailed guidelines for each architectural layer.

Functional Areas

Applications are usually composed from distinct functional areas, like a publication editor and a news list. The code for a functional area should be grouped together and separated from other functional areas, so it can be developed, tested and profiled independently.

The code for a functional area is contained beneath a single source package. Although multiple functional areas may be contained within a single Flash Builder project, it is common to extract them into modules or sub-applications, stored is separate application projects. Shared infrastructure code, such as reusable components and utilities, is best extracted into library projects.

Functional areas usually contain their own presentation and application layers. They sometimes contain their own domain models, but other times share some domain knowledge with other functional areas. In that case, the shared domain models are normally extracted into library projects that functional areas can depend upon.

Functional areas interact with one another through thin interfaces. These typically consist of events and ActionScript interfaces. Shared infrastructure, such as a messaging framework or service registry is often used to facilitate interactions.

Functional areas also reuse components, styles and skins for a consistent look and feel and to prevent code duplication. These are a kind of infrastructure, like the components in the Flex SDK, that should be designed without knowledge of the particular business domain of an application.

Design Patterns

Design patterns are repeatable solutions to commonly occurring problems in software design. Cairngorm catalogues a number of design patterns that are effective in Flex. They can be applied within functional areas and across layers to bring consistency to a large code base. For example, the Command pattern is advocated for encapsulating operations and the Presentation Model is advocated for removing state and logic from MXML view components.

Conclusion

The Cairngorm architecture recommends composing larger applications from smaller parts, known as functional areas. It recommends separating code into architectural layers, based on the kind of responsibilities that are carried out. And it recommends applying consistent design patterns to solve recurring problems and advocates a number of these that have proven useful in Flex applications.

An analogy for the Cairngorm architecture might be a number of businesses doing work together. Each business premises is a functional area. The building's exterior and decoration is its presentation layer. Inside there are people carrying out tasks and they are the application layer. The business that is accomplished – the products created and sold – is the domain layer, and the building materials, telephones and coffee machines that facilitate the whole enterprise are the infrastructure layer.

To find out more about the Cairngorm architecture, you can refer to the documentation on the Cairngorm Guidlines page and the sample applications.

References

Evans, E. (August 2003). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.