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.

1. APPLICATION
ARCHITECTURE
JUMPSTART
Clint Edmonson
Polaris Solutions
clinted@polarissolutions.com

2. Platinum Sponsors
Silver Sponsors
Gold Sponsors

4. Who the heck needs architecture?

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

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

14. THE GOAL OF ARCHITECTURE
Eliminate the things I don’t want to think
about.
Keep complexity at bay!

16. How do we tackle this complexity?

17. Abstraction Layering

18. Partitioning

19. CONQUERING COMPLEXITY
• Abstraction
• Layering
• Partitioning
• Occam’s Razor

20. ITERATIVE ARCHITECTURE & DESIGN
Page 41

21. 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 & Maintainers
• Testers
• Operations

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

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

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

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

26. 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
- Checkout
Check an order status
Cancel an order
Get a refund on an order
View order history
Receive shipping notifications
Receive special offers and coupons
- "registered" customers only
Rate toys
Write reviews of toys
Process open orders
- View list of open orders
- Fulfill an order (ship & close it)
- Cancel and refund an order
View sales reports
- conversions, abandonments, etc.
Send special offers to "registered"
customers
Manage customer accounts
- Reset passwords
- Delete accounts
Manage inventory
- Manage product categories
- Manage inventory levels
- Place products on back order
Generate monthly sales reports
Send 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.

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

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

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

30. FUNDAMENTAL DESIGN TOOLS
• Layers
• Assemblies
• Namespaces

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

32. COMMON APPLICATION
ARCHITECTURE
Page 10

33. CASE STUDY
A naïve approach…

34. BASELINE LAYERED ARCHITECTURE
Tailspin Backoffice
Admin
Tailspin Backoffice
Admin
Email Server
Tailspin.Core
Payment
Processor
Payment
Processor
Tailspin.Database
Tailspin.Domain
Browser
Tailspin.Web Tailspin.WebJob

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

36. COMPONENT DESIGN
Database Server
Website
Tailspin.Web
Tailspin.Domain Tailspin.Core
Tailspin.WebJob
Tailspin.Database
SendGrid Stripe

37. PHYSICAL ARCHITECTURE
Azure Data Center
:Website
Azure Load
Balancer
User
:Website
:SQL Azure
Database
:Payment
Processor
:Search Service
...
:Webjob
:SendGrid
https
https
TDS
https
https
TDS
https
https

38. CASE STUDY
Something more reasonable…

39. 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!

40. Rinse, repeat, refactor…
Page 41

41. ANALYSIS & DESIGN ARTIFACTS
• Sketch
• Blueprint
• Executable
• They are artifacts, not documentation!
• Don’t be afraid to throw them away and draw new ones!

42. More case studies…

43. CHARACTERISTICS of a GOOD
ARCHITECTURE
• Form Follows Function
Evolutionary not pre-ordained or predicted
• Functional alignment & partitioning
• One right place
• Keeps complexity in check
• Facilitates/accelerates feature delivery

44. STUDY OTHERS’ ARCHITECTURES
Open Source Projects
HighScalability.com
Is it easy to understand?
Is it easy to find things?
How would you have done it differently?

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

46. REFERENCES
• Microsoft Application Architecture Guide 2nd Edition
by Microsoft Patterns & Practices Group
• Microsoft .NET: Architecting Application for the Enterprise
by Dino Esposito & Andrea Saltarello
• Domain Driven Design
by Eric Evans
• Framework Design Guidelines
by Krzysztof Cwalina & Brad Abrams

47. Q & A

48. Clint Edmonson
Polaris Solutions
clinted@polarissolutions.com
Stop by our booth and chat!