App Architecture Guide

As part of my preparation for writing a new application architecture guide, I’m analyzing our original patterns & practices Application Architecture Guide.  Below I show what I think is the most important blueprints from the original guide.

Application Architecture (Canonical)

This is the original patterns & practices application architecture:

 

Application Architecture Explained

The following is a brief explanation of the patterns & practices application architecture.

1. User interface (UI) components. Most solutions need to provide a way for users to interact with the application. UI components render and format data for users and to acquire and validate data coming in from them.
2. User process components. In many cases, a user interaction with the system follows a predictable process. To help synchronize and orchestrate these user interactions, it can be useful to drive the process using separate user process components. 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 “engine” can be reused by multiple user interfaces.
3. Business components. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks. Business components implement the business logic of the application.
4. Business workflows. After the required data is collected by a user process, the data can be used to perform a business process. Business workflows define and coordinate long-running, multi-step business processes.
5. Service agents. When a business component needs to use functionality provided in an external service, you may need to provide some code to manage the semantics of communicating with that particular service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires.
6. Service interfaces. To expose business logic as a service, you must create service interfaces that support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) its different consumers require. Service interfaces are sometimes referred to as business facades.
7. Data access logic components. Most applications and services will need to access a data store at some point during a business process. It makes sense to abstract the logic necessary to access data in a separate layer of data access logic components. Doing so centralizes data access functionality and makes it easier to configure and maintain.
8. Business entity components: Most applications require data to be passed between components. For example, in the retail application a list of products must be passed from the data access logic components to the user interface components so that the product list can be displayed to the users. The data is used to represent real-world business entities, such as products or orders. The business entities that are used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.
9. Components for security, operational management, and communication: Your application will probably also use components to perform exception management, to authorize users to perform certain tasks, and to communicate with other services and applications.

Presentation, Business, and Data Layer

The guide uses presentation, business and data layers to organize and contain application logic.

My Related Posts

• App Types
• App Infrastructure Frame
• Architecture Styles