Application Patterns for Application Architecture


We created an initial set of Application Patterns as part of our patterns & practices Application Architecture Guide 2.0 project.   The purpose of the application patterns is to show a skeletal solution for common end-to-end applications.  Each application pattern includes a scenario, a pattern solution, and a technical solution.  This provides you with a relatively stable backdrop and starting point to reuse lessons learned from successful applications.

Application Patterns
Here’s our initial set of application patterns:

Example Application Pattern
The heart of each application pattern revolves around the scenario, the pattern overlay, and the technology overlay:

Scenario
Here’s the backdrop we use for the baseline architecture:

Scenario

Pattern Solution
Here’s our pattern overlay:

PatternsSolution (2)

Tech Solution
Here’s our technology overlay:

TechnologySolution (2)

Application Pattern Template
Here’s the core structure of each application pattern:

Section Description
Key Characteristics Identifies the distinctions that impact the application architecture and design. Helps you quickly identify whether the scenario is relevant for your situation.
Scenario A brief illustration of the deployment scenario and main application parts.
Key Characteristics Identifies the distinctions that impact the application architecture and design. Helps you quickly identify whether the scenario is relevant for your situation.
Pattern Solution Provides an overaly of patterns on top of the key application parts.
Pattern Solution Details Elaborates on the patterns. Includes pattern summaries and any relevant example information.
Technical Solution Provides an example overlay of technologies.
Technical Solution Details Elaborates on the technologies. Includes technology summaries and any relevant example information, such as code snippets or psuedocode.
Additional Resources Provides a set of directly relevant resources where you can find more information.

Feedback

  1. What are 3 things you like about the approach?
  2. What are 3 things you would improve?

My Related Posts

Comments (7)

  1. Colin Jack says:

    Just on terminology I think "Two-Tier Service Application Scenario (REST)" is more accurate than "Web Service with REST Application Pattern" because the former indicates it is just one of many possible ways to implement a REST architecture.

  2. It was interesting that all the fuss over Oxite had a positive impact. Unfortunately Microsoft are also

  3. Colin Jack says:

    I’ve just read the "Web Service with REST Application Pattern" guidance and have to say I think its surprisingly poor, I really hope you guys reach out to the domain modeling(DDD)/REST/SOA/messaging communities in future as I think it would be to the benefit of all involved.

  4. Colin,

    I just posted a thread to your web site for the thread on this topic.  Since we use an agile process around here, we get things out early and then review and improve them. We are happy to send you out the source Word document and have you mark up the document on what should be improved.

    Thanks for giving your opinion. We do appreciate the feedback.

    Rob

  5. Thank you for submitting this cool story – Trackback from DotNetShoutout