The document outlines a structured approach to application architecture, emphasizing the importance of defining objectives, identifying key scenarios, and creating an application overview. It details the process for developing a layered architecture, including considerations for cross-cutting concerns and deployment strategies. Best practices are provided to minimize design complexity and enhance the architectural integrity of the application.

1. A P P L I C AT I O N
ARCHITECTURE
J U M P S TA R T
Clint Edmonson
Senior Consultant
Polaris Solutions
clinted@polarissolutions.com

2. Platinum
Sponsors
Gold Sponsors
Silver
Sponsors

4. Who the heck needs architecture?

12. CONQUERING COMPLEXITY
• Abstraction
• Partitioning

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

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

16. ITERATIVE ARCHITECTURE & DESIGN
Page 41

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

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

19. BRAINSTORMING SCOPE & KEY SCENARIOS

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

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

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

23. FUNDAMENTAL DESIGN TOOLS
• Layers
• Assemblies
• Namespaces

24. COMMON APPLICATION
ARCHITECTURE
Page 10

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

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

27. BASELINE LAYERED ARCHITECTURE

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

29. Baseline physical deployment

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

31. Rinse, repeat, refactor…
Page 41

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

33. Architecture after several iterations

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

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

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

37. Q&A