Architecture is about looking at a system from a point of view that makes it appear simple, sometimes artificially so. An architectural viewpoint has to be simple to understand, to describe, to compare with other viewpoints, and, ultimately, to implement. The viewpoint might seek a broad approach to a big, sweeping problem. Then again, it might be a thematic idea that can generate a family of similar solutions to a crowd of similar little problems—that is, a design pattern. Either way, architecture provides a way of looking at the "conceptual essence" of something without getting bogged down in every detail.
Adopting such a viewpoint inevitably limits one's implementation choices. That can be good. If all options are open, ten similar problems in your project might get solved using ten different techniques. That can require up to ten times more work than solving them all with a single technique, outweighing the usually meager benefits of handcrafting each solution. It can take up to ten times as much effort for a new developer to understand how the code works. And when it comes time to change the approach(es), it might take up to ten times as much effort to make that change (since you'd have ten different starting points). So, limiting variation saves time, makes things much easier to understand, and lets you discover and factor out common code much more easily.
When we simplify enough, and in the right way, we wind up with a viewpoint that contains a small number of concepts to think about, each of which has a clear set of responsibilities, relationships, and interactions with the others. It points the way forward on multiple fronts. A viewpoint like that is usually a sign of a successful architecture.
In this article, I present an architecture with concrete, identifiable benefits and costs, relative to a specific example. This article does not demonstrate a "right" architecture for Flex. Don't make me laugh (or cry)! There is no architecture that is general enough to be called "right."
My view of architectures is that they are not "right" or "wrong"; they are "worth the effort" or "not worth the effort" for a particular job to be done. (Granted, some architectures actually are wrong. But those are the ones that really aren't worth the effort!)
There will generally be multiple architectures that work in a given domain. They can be compared with each other. You can say what's good about them and what's bad. And you can pick one that's worth the effort, knowing the limitations that come with it. So, although the approaches outlined here are appropriate in many different circumstances, be ready to adapt them, or even discard them, in favor of something that is "worth it" for your particular purposes. Above all, I hope to present an example of what "worth it" looks like, from a specific vantage point.