Application architecture jumpstart

Preview:

DESCRIPTION

This presentation distills the best industry guidance into a hands-on approach to designing application architectures. Along the way, we'll examine the key decisions that must be made when choosing our architectural styles and designing our layers and show how those decisions turn into real shippable code on a project.

Citation preview

APPLICATION ARCHITECTURE JUMPSTART

Clint Edmonson

Senior Consultant

Polaris Solutions

clinted@polarissolutions.com

Platinum Sponsors

Silver Sponsors

Gold Sponsors

Who the heck needs architecture?

CONQUERING COMPLEXITY

• Abstraction• Partitioning

ARCHITECTURE

“A unifying or coherent form or structure.” merriam-webster.com

DESIGN

“Design, at its most fundamental, is about finding solutions.” Garr Reynolds

1. Identify architecture objectives

A. Determine goals based on size, scope, time• Complete application• Prototype• Solving a technical risk• Exploring potential options• Building shared, reference models

B. Identify target audience• Other architects• Developers• Testers• Operations

2. Identify key scenarios

A. Define the solution’s boundaries

B. Identify who will impacted by the solution

C. Discover what valuable activities will be automated

D. Uncover constraints that will limit the solution

E. Identify activities that are most important to the success of your application

F. Highlight those that are architecturally significant

BRAINSTORMING SCOPE & KEY SCENARIOS

3. Create an application overview

A. Determine your application type• Web• Mobile• Rich client• RIA• Web service• Some combination of the above

B. Identify your deployment constraints

C. Determine your relevant technologies

4. Identify key issues

A. Cross-cutting concerns• Configuration• Security• Communication• Compression• Encryption• Logging & instrumentation• Validation• Error management

B. Quality attributes• Run-time performance • Scalability• Disaster recovery

5. Define candidate solution(s)

A. Choose an architecturally significant scenario

B. Design a candidate baseline architecture

C. Build out the scenario to prove it out

FUNDAMENTAL DESIGN TOOLS

• Layers

• Assemblies

• Namespaces

LAY(ER)ING IT ALL OUT

• Describe the application at a high level

• Identify major functional units of the design and their interdependencies

• Each layer represents a logical group of projects, namespaces, and/or other artifacts

LAYERED ARCHITECTURE DESIGN STEPS

1. Determine layers you require

2. Determine rules for interaction between layers

3. Identify cross-cutting concerns

4. Determine if you need to collapse layers

5. Choose deployment strategy

BASELINE LAYERED ARCHITECTURE

Physical deployment• Visualize the physical structure of a system

• Executables• Libraries• Services

• Focus on components of the system, their relationships, interfaces, and ports

• Highlight the service behavior that they provide and consume through interfaces

Baseline physical deployment

Grouping layers into assemblies

• Prefer fewer, larger assemblies• Faster load time• Reduced working set• Better NGEN optimization• If several assemblies are always loaded together, consider

combining them into one

• Partition into separate assemblies based on• Deployment• Versioning• Data access• Security and access control• Contributions from disparate sources

• Avoid the one dll per namespace anti-pattern!

ANALYSIS & DESIGN ARTIFACTS

• Sketch• Blueprint• Executable

• They are artifacts, not documentation!• Don’t be afraid to throw them away and draw new ones!

Architecture after several iterations

BEST PRACTICES• Minimize upfront design

• avoid starting more than one layer/namespace deep

• Analyze and refactor at the beginning of each iteration

• Separate functional areas of concern cleanly

• Avoid duplicating responsibilities

• Minimize dependencies between layers

• Make it obvious where code needs to go!

LAW OF PARSIMONY

“Reduce everything to its essence so that form harmonizes with function.” Chris Kobryn

REFERENCES

• Microsoft Application Architecture Guide 2nd Editionby Microsoft Patterns & Practices Group

• Microsoft .NET: Architecting Application for the Enterpriseby Dino Esposito & Andrea Saltarello

• Domain Driven Design by Eric Evans

• Framework Design Guidelines by Krzysztof Cwalina & Brad Abrams

Q & A

Recommended