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

3. Who the heck needs architecture?

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

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

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

15. How do we tackle this complexity?

16. Abstraction Layering

17. Partitioning

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

19. ITERATIVE ARCHITECTURE & DESIGN
Page 41

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

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

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

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

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

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

26. 3. Create an application overview
A. Determine your application type(s)
• Web
• Mobile
• Rich client
• RIA
• Web service
• Some combination of the above
B. Identify your deployment constraints
C. Determine your relevant technologies

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

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

29. FUNDAMENTAL DESIGN TOOLS
• Layers
• Assemblies
• Namespaces

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

31. COMMON APPLICATION
ARCHITECTURE
Page 10

32. CASE STUDY
A naïve approach…

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

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

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

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

37. CASE STUDY
Something more reasonable…

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

39. Rinse, repeat, refactor…
Page 41

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

41. More case studies…

42. CHARACTERISTICS of a GOOD
ARCHITECTURE
• Form Follows Function
Evolutionary not pre-ordained or predicted
• Functional alignment & partitioning
• One right place for non-trivial code
• Obvious where the next line of code needs to go
• Keeps complexity in check
• Facilitates/accelerates feature delivery

43. 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?

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

45. Q & A

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