Microsoft Application Architecture Solution Summary

Our goal

User

1.Requirement

2.User activity

3.Future Requirement

System

1.Design(Open for change)

2.Performance

3.Security

4.Deploy strategy

5.Reuse Existing technology

Business

1.Flow

2.Key scenarios

Key Questions :

· How will the users be using the application?

· How will the application be deployed into production and managed?

· What are the quality attribute requirements for the application, such as security,

performance,concurrency, internationalization, and configuration?

· How can the application be designed to be flexible and maintainable overtime?

· What are the architectural trends that might impact your application now or after

it has been deployed?

Keep in mind that thearchitecture should:

· Expose the structure of the system but hide the implementation details.

· Realize all of the use cases and (Key)scenarios.

· Try to address the requirements of various stakeholders.

· Handle both functional and quality requirements(Attributes).

Key Principles of Software

Key Questions

· What are the foundational parts ofthe architecture that represent the greatest risk

if you get them wrong?

· What are the parts of thearchitecture that are most likely to change, or whose

design you can delay untillater with little impact?

· What are your key assumptions, andhow will you test them?

· What conditions may require you torefactor the design?

1.Buildto change

2.Modelto analyze

Architecture Overview

Key Principles

Separation of Concern

Separate system concerns ,such as log , exception , cache handling . handle them using Aspect programming .

Single Responsibility

Each class, component only focus doing 1 thing

Least Knowledge

1 component or object should not know details about the internal implementation about another component or object .

Do not repeat yourself

Do implement 1 feature in 1 place

Minimize design

On design what is necessary , design can also scrum and optimize as changing happening .

Design practices

Keep designconsistent within each layer

DRY

Prefer composition to inheritance

Establishcoding style and naming convention

Maintainsystem quality using QA tool

Systeminteraction , Layer communication , clear contract

Use abstraction (interface , abstract class , plug-in design , message) for loose couple design

Deploystrategy

Application Type

1.Mobiledevices

2.RIA

3.WebApplications

4.Service

5.Couldbased

6.Sharepoint

Deployment Strategy

1.Distribute

2.non distribute

Appropriate Tech

What technology to use in each layer

Consider organization police , infrastructure limit

Quality Attributes

1.functionality

2.performance

3.Userexperience

4.Security

5.Maintain

Keyquestions :

What arethe key quality attributes required for your application? Identify them as

part of thedesign process.

What arethe key requirements for addressing these attributes? Are they actually

quantifiable?

What are the acceptance criteria that will indicate that you have met the requirements?

Crosscutting concern

1.Logging

2.Authenticationand authorization

3.Exception

4.Communication

5.Cache

Architectural patterns& Style

Category	Architecture Styles
Communication	SOA , Message bus
Deployment	Client / Service , N-tier , 3- tier
Domain	DDD
Structure	Component-based, OO ,layered

Client Server

a.Client– (server based)queue – client

b.P2P

c.Applicationserver :thin client send command , server execute application

Benefits :

Higher security

Centralize data access

Ease of maintain

Component Based

Focuses on decomposition of the design into individual functional orlogical components, expose well-defined communication interface(method , event, property)

Key principle :

a.Reusable

b.Replaceable

c.Notcontext specific

d.Extensible

e.Encapsulate

f.Independent

Component architectures manage the mechanics of locating components and their interfaces,passing messages or commands between components, and—in some cases—maintaining state

Benefits

a.Easeof deployment

b.Reducecost (reuse third party or open source component )

c.Easeof development

d.Reducecomplexity

Design patterns such as the Dependency Injection pattern or the Service Locator

pattern canbe used to manage dependencies between components,and promote

loosecoupling and reuse .

Domain driven design

Model business into domain model class .consider use DDD if domain(scenarios) is complex and wish to improve communication and understanding within development team .

Benefits :

Communication. All parties within a development team can use the domain model

and the entities it defines to communicate business knowledge and requirements

using a common business domain language, without requiring technicaljargon.

Extensible. The domain model is often modular and flexible, making it easy to

update and extend as conditions and requirements change.

Testable. The domain model objects are loosely coupled and cohesive,allowing

them to be more easily tested.

Layered

Focus on grouping related functionality(component )

Communication between each layer is explicit and loose coupled , can deploy separately

Benefits

a.Abstraction

b.Encapsulation

c.Cleardefined functional layers

d.Highcohesion

e.Reusable

f.Loosecouple : communication is based on abstraction ,event ,message to provide loosecouple design

Message bus

a.Message oriented

b.Complex logic can be executed by combining small logic unit and command

c.Integration with different environments

d.Plug-in design , allow insert application into current system

Benefits

Extensibility

Low complexity

Flexibility

Loose coupe

Scalability : can add new application to current bus

Application simplicity (applications communication only need to link to message bus , no need know each other)

N-tier / 3-tier

Tier is physical structure , layer is logical structure

Tier should be completely separate from each other

Deploy separately

For security consideration , may need to deploy business component behind fire wall

O-O

Objects are discrete, independent, and loosely coupled; they communicate through interfaces,by calling methods or accessing propertiesin other objects, and by sending and receiving messages.

Commonly , use OO combine with DDD pattern ,to model application business .

a.Abstraction

b.Composition

c.Encapsulation

d.Decouple

Benefits

Understandable

Reusable (polymorphism , abstraction)

Testable (well encapsulation )

Extensible (encapsulation , loose couple design )

Highly cohesive

SOA

1.Multiple client & different protocols support

2.Communication between different systems

3.Focus on providing message based interaction

4.Package business processes into interoperable services using a range of protocols and data formats to communicate information

Technique for Architectureand Design

Input , output , DesignSteps

Scenarios

Functional requirement

Quality attributes

Deployment

Interactive architecture activity

Key Scenarios

Use key scenarios tofocus your design on what matters most .

achieve a balancebetween user ,business and system .

key scenarios are thoseconsidered most important for the success of application .

Key Issues

Identify key issuesbased on quality attributes and crosscutting concern .

Quality attributes :Performance(design , deploy , communicate ,cache ,implementation , etc.) ,Security(Deploy , protocol ,communicate) ,maintenance(Design) , UE

Crosscutting concern :

Authentication &authorization , cache , communication , configuration , exception ,logging ,validation .

Application Overview

A.Application type

B.Identifydeployment constraints

C.Considerarchitecture style

D.Determinerelevant technology

Mobile application

Rich client application : AJAX service , WPF

Web Application : Web Form , Asp.net MVC , AJAX , Web API

Services : ASMX , WCF

Others :

The Microsoft Application Platform

Presentation Technology Matrix

Data Access Technology Matrix

Integration Technology Matrix

Workflow Technology Matrix

Candidate Solutions

Architecture base line +design + scenario based

4+1 :

4 views : logical view(object model) , process view (business flow , concurrency) ,

Physical view (deploy view),development view