Here are some basic rules that I have observed about how to make a Cairngorm application. I've categorized these rules by the parts of Cairngorm's underlaying MVCS design pattern: Model, View, Controller, Service.
MODEL:
There is one singleton Model Locator, which stores all state data in the application. The Model Locator is basically a bank of Value Objects.
Value Objects can be data-bound to the view. This means that when the data is updated, the model dispatches an internal event within Flex, and the views will listen to these events.
VIEWS:
The views listen to the changes broadcast by the Model and update the UI as necessary. This is done through data-binding, a technique in Flex that automatically updates the view when the model changes.
The view never updates the Model data directly.
In Flex, the view is usually implemented as an mxml component. MXML is similar to HTML.
The view can broadcast an event to the Front Controller.
When your app grows to where there is a significant view hierarchy, you may bubble non-Cairngorm view events up to a high-level view container, and then have that container dispatch Cairngorm events to the Front Controller.
CONTROLLERS:
The only object that may respond to a Cairngorm event begin broadcast by a view is the Front Controller singleton.
The command object is the only object that should update the Data Model.
A command object should not create another command object to perform a task. Instead it should create a command delegate.
A command object should not parse data. Only the command delegate should do parsing, and the delegate should return application-structured data to the command object. The command object should not be exposed to raw server data.
A command object may instantiate many command delegates. Each instance of a command delegate should have exactly one command object instance to report back to when data comes in.
The command delegate is the only object allowed to invoke a call to the Service Locator.
SERVICES:
The service locator singleton is a bank of supported services.
A service may communicate data with the server by any means necessary, for example: HTTP send/receive, Flash Media Server stream, Periodic HTTP calls to the server to trigger changes to its response.
Only a service contained in the service locator is allowed to communicate with outside data sources.
A service locator may NOT update the Model directly. It is only allowed to send information to the command delegate that it was instantiated by.