application architecture jumpstart

APPLICATION ARCHITECTURE JUMPSTARTClint EdmonsonPolaris Solutionsclinted@polarissolutions.com

Platinum Sponsors

Silver Sponsors

Gold Sponsors

Who the heck needs architecture?

ARCHITECTURE

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

DESIGN

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

THE GOAL OF ARCHITECTURE

Eliminate the things I don’t want to think about.

Keep complexity at bay!

How do we tackle this complexity?

Abstraction Layering

Partitioning

CONQUERING COMPLEXITY

• Abstraction

• Layering• Partitioning

• Occam’s Razor

ITERATIVE ARCHITECTURE & DESIGN

Page 41

1. Identify architecture objectivesA. 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 & Maintainers• Testers• Operations

2. Identify key scenariosA. 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

CONTEXT DIAGRAM

Tailspin Toys

Tailspin Toys is a small brick and mortar model airplane shop that wants an online store front to supplement in-store sales.

CONTEXT DIAGRAM

Tailspin Toys

Non-functional Requirements & Constraints - Web based solution to achieve customer reach - Support mobile browsers - Hosted by a third party web hosting provider - Must integrate with existing inventory database and administrative tools

Tailspin Toys is a small brick and mortar model airplane shop that wants an online store front to supplement in-store sales.

CONTEXT DIAGRAM

Tailspin Toys

Non-functional Requirements & Constraints - Web based solution to achieve customer reach - Support mobile browsers - Hosted by a third party web hosting provider - Must integrate with existing inventory database and administrative tools

Customer

Store Manager

Time

Tailspin Toys is a small brick and mortar model airplane shop that wants an online store front to supplement in-store sales.

CONTEXT DIAGRAM

Payment ProcessorTailspin Toys

Non-functional Requirements & Constraints - Web based solution to achieve customer reach - Support mobile browsers - Hosted by a third party web hosting provider - Must integrate with existing inventory database and administrative tools

Customer

Store Manager

Time

Shop for Toys - Browse by category - Browse by price range - Search by name - View list of best sellers - View toy details - Read reviews of toys - Add toys to shopping cart - Add toys to wishlist - View shopping cart contents - View other customers' wishlists - CheckoutCheck an order statusCancel an orderGet a refund on an orderView order historyReceive shipping notificationsReceive special offers and coupons - "registered" customers onlyRate toysWrite reviews of toys

Process open orders - View list of open orders - Fulfill an order (ship & close it) - Cancel and refund an orderView sales reports - conversions, abandonments, etc.Send special offers to "registered" customersManage customer accounts - Reset passwords - Delete accountsManage inventory - Manage product categories - Manage inventory levels - Place products on back order

Generate monthly sales reportsSend coupons to "infrequent" customers

Tailspin Toys is a small brick and mortar model airplane shop that wants an online store front to supplement in-store sales.

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 constraintsC. 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

COMMON APPLICATION ARCHITECTURE

Page 10

CASE STUDY

A naïve approach…

BASELINE LAYERED ARCHITECTURE

Tailspin BackofficeAdmin

Tailspin BackofficeAdmin

Email Server

Tailspin.Core

PaymentProcessorPayment

ProcessorTailspin.Database

Tailspin.Domain

Browser

Tailspin.Web Tailspin.WebJob

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

COMPONENT DESIGN

Database Server

Website

Tailspin.Web

Tailspin.Domain Tailspin.Core

Tailspin.WebJob

Tailspin.DatabaseSendGrid Stripe

PHYSICAL ARCHITECTUREAzure Data Center

:Website

Azure Load Balancer

User

:Website

:SQL Azure Database

:Payment Processor

:Search Serv ice

...

:Webjob

:SendGrid

https

https

TDS

https

https

TDShttps

https

CASE STUDY

Something more reasonable…

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!

Rinse, repeat, refactor…

Page 41

ANALYSIS & DESIGN ARTIFACTS• Sketch• Blueprint• Executable

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

More case studies…

CHARACTERISTICS of a GOOD ARCHITECTURE

• Form Follows FunctionEvolutionary not pre-ordained or predicted

• Functional alignment & partitioning

• One right place

• Keeps complexity in check

• Facilitates/accelerates feature delivery

STUDY OTHERS’ ARCHITECTURES

Open Source ProjectsHighScalability.com

Is it easy to understand?Is it easy to find things?How would you have done it differently?

LAW OF PARSIMONY

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

REFERENCES• Microsoft Application Architecture Guide 2nd Edition

by 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

Clint EdmonsonPolaris Solutionsclinted@polarissolutions.com

Stop by our booth and chat!