• Skip to main content
  • Skip to header right navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Engineering Books
  • Lessons in Software
  • Archives
  • JD Meier.com

App Architecture Guide

Jun 1, 2008 by JD

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:

AppArch 

Application Architecture Explained

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

AppArchExplained

  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.

AppArchPresentationBusinessDataLayers

My Related Posts

  • App Types
  • App Infrastructure Frame
  • Architecture Styles
Category: ArchitectureTag: Architecture, Design

About JD

Previous Post:App Types (Archetypes)
Next Post:Web Apps, Smart Clients, Web Services, and Data Access

Reader Interactions

Trackbacks

  1. Web Apps, Smart Clients, Web Services, and Data Access says:
    Jun 1, 2008 at 7:43 am

    […] App Architecture Guide […]

Sidebar

Recent Posts

  • Best Software Books of All Time According to a Microsoft Exec
  • How To Effectively Pitch a Business Idea (Customer, Problem, Competition, and Success)
  • Customer-Connected Engineering at patterns & practices
  • Lessons in Software Development from Eric Brechner
  • Best Practices at patterns & practices

Popular Posts

Best Software Engineering Books
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future