In my previous post, I summarized layers and tiers.  In this post, I'll walk through the key components of the layers.  This exercise is part of our patterns & practices App Arch Guide 2.0 project.

Layers and Components
Here's a visual of a layered architecture and relevant components:

Note that this is just an example of common components and layers.  Your scenarios may vary.

Presentation Layer Components
Here's typical presentation layer components:

• User interface (UI) components. Your user interface components (controls) provide a way for users to interact with your application. They render and format data for users and acquire and validate data coming in from them.
• User process components. Your user process components help synchronize and orchestrate user interactions. This way the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction patterns can be reused by multiple user interfaces.

Business Layer Components
Here's typical business layer components:

• Application Facade. (Optional).  Your application facade maps your business logic to your application.  It's optional and it depends on how reusable and generic your business logic is.  If your business logic was written specifically for your application, then you probably don't need an application facade.
• Business components. Your business components implement business rules and perform business tasks.
• Business workflows. Your business workflows define and coordinate long-running, multi-step business processes.  They can be implemented using business process management tools.
• Business entity components. Your business entity components represent actual business entities (for example products or orders.)  You use them to pass data between components.  They're usually data structures (such as DataSets, DataReaders, or XML streams), but they can also be implemented using custom object-oriented classes.

Data Layer Components
Here's typical data layer components:

• Data access logic components. Data access components abstract the logic necessary to access. Doing so centralizes data access functionality and makes it easier to configure and maintain.
• Data Helpers / Utilities.   
• Service agents. Your service agents help you call external services.  They do so by mapping the format of the data exposed by the service to the format your application uses, as well as help manage the semantics of calling the services.

Cross-Cutting

• Cross-cutting components.  This includes components  components to perform exception management, to authorize users to perform certain tasks, and to communicate with other services and applications.

Feedback
Does this match what you see in practice?

Additional Resources
Here's some relevant links:

• Designing the Components of an Application or Service (App Arch Guide)
• Layered Application (Enterprise Solution Patterns)

My Related Posts

• patterns & practices App Arch Guide 2.0 Project
• Layers and Tiers
• App Arch Meta Frame
• Scenario Frames for Presentation, Business, Data and Services