This presentation distills the best guidance from the Microsoft Patterns & Practices group to provide 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 a real shippable code on a project.

1. Architecting Applications the Microsoft Way Clint Edmonson Developer Evangelist Microsoft Corporation

2. Who the heck needs architecture?

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

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

12. A technique for architecture & design Page 41

13. 1. Identify architecture objectives Goals based on size, scope, time Complete application Prototype Solving a technical risk Exploring potential options Building shared, reference models Target audience Other architects Developers Testers Operations

14. 2. Identify key scenarios Define the solution’s boundaries Identify who will impacted by the solution Discover what valuable activities will be automated Uncover constraints that will limit the solution Highlight those that are most important to the success of your application

15. Brainstorming scope & key scenarios

16. 3. Create an application overview Determine your application type Web Mobile Rich client RIA Web service Some combination of the above Identify your deployment constraints Determine your relevant technologies Identify important architectural styles

17. Architecture styles Layered Client/server Component-based Domain driven design Message bus N-Tier Object-oriented Service-oriented This is our architecture toolbox!

18. 4. Identify key issues Cross-cutting concerns Configuration Security Communication Compression Encryption Logging & instrumentation Validation Error management Quality attributes Run-time performance Scalability Disaster recovery

19. 5. Define candidate solution(s) Choose an architecturally significant scenario Design out a baseline architecture Prove it out

20. Common Application Architecture Page 10

21. Lay(er)ing it all out Describe the application at a high level Identify major components and other functional units of the design and their interdependencies Each layer represents a logical group of projects, namespaces, and/or other artifacts

22. Layered structure design steps Determine layers you require Determine rules for interaction between layers Identify cross-cutting concerns Determine if you need to collapse layers Choose deployment strategy

23. Presentation layer UI Components Presentation Layer Logic Components Navigation Error handling Validation

24. Services layer Authentication Authorization Communication & messaging format Exception handling

25. Business layer Authentication Authorization Exception handling Logging, auditing, & instrumentation Validation

26. Data layer Batching Blobs Connections Data format Exception management O/R mapping Transactions Validation

27. Initial 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. 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 Security control Independent versioning Data access Contributions from disparate sources

31. Rinse, repeat, refactor… Page 41

32. Architecture after several iterations

33. Key architecture principles Separation of Concerns Single Responsibility Principle Principle of Least Knowledge Don’t Repeat Yourself Minimize Upfront Design

34. Best Practices Minimize upfront design avoid starting more than 1 namespace deep when layering 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. References Microsoft Application Architecture Guide 2nd Edition by Microsoft Patterns & Practices Group Microsoft .NET: Architecting Application for the Enterprise by Dino Esposito & Andrea Salterello Domain Driven Design by Eric Evans Framework Design Guidelines by Krzysztof Cwalina & Brad Abrams

36. Call to action Download the trial Available now on MSDN Team blog: http://blogs.msdn.com/vsarch Stayed tuned to my blog for more… http://www.notsotrivial.net clinted@microsoft.com

37. Q & A

38. © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.