0
Architecting Applications the Microsoft Way<br />Clint Edmonson<br />Developer Evangelist<br />Microsoft Corporation<br />
Who the heck needs architecture?<br />
Architecture<br />“A unifying or coherent form or structure.”<br />     merriam-webster.com<br />
Design<br />“Design, at its most fundamental, is about finding solutions.”<br />     Garr Reynolds<br />
A technique for architecture & design<br />Page 41<br />
1. Identify architecture objectives<br />Goals based on size, scope, time<br />Complete application<br />Prototype<br />So...
2. Identify key scenarios<br />Define the solution’s boundaries<br />Identify who will impacted by the solution<br />Disco...
Brainstorming scope & key scenarios<br />
3. Create an application overview<br />Determine your application type<br />Web<br />Mobile<br />Rich client<br />RIA<br /...
Architecture styles<br />Layered<br />Client/server<br />Component-based<br />Domain driven design <br />Message bus<br />...
4. Identify key issues<br />Cross-cutting concerns<br />Configuration<br />Security<br />Communication<br />Compression<br...
5. Define candidate solution(s)<br />Choose an architecturally significant scenario <br />Design out a baseline architectu...
Common Application Architecture<br />Page 10<br />
Lay(er)ing it all out<br />Describe the application at a high level <br />Identify major components and other functional u...
Layered structure design steps<br />Determine layers you require<br />Determine rules for interaction between layers<br />...
Presentation layer<br />UI Components<br />Presentation Layer Logic Components<br />Navigation<br />Error handling<br />Va...
Services layer<br />Authentication<br />Authorization<br />Communication & messaging format<br />Exception handling<br />
Business layer<br />Authentication<br />Authorization<br />Exception handling<br />Logging, auditing, & instrumentation<br...
Data layer<br />Batching<br />Blobs<br />Connections<br />Data format<br />Exception management<br />O/R mapping<br />Tran...
Initial architecture<br />
Physical deployment<br />Visualize the physical structure of a system <br />Executables<br />Libraries<br />Services<br />...
Physical deployment<br />
Grouping layers into assemblies<br />Prefer fewer, larger assemblies<br />Faster load time<br />Reduced working set<br />B...
Rinse, repeat, refactor…<br />Page 41<br />
Upcoming SlideShare
Loading in...5
×

Architecting Applications the Microsoft Way

6,517

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
6,517
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
116
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Photo credits: http://www.flickr.com/photos/cogdog/2708223050/Creative Commons Attribution License
  • Photo credits: http://www.flickr.com/photos/dullhunk/2859826117/Creative Commons Attribution License
  • Photo credits: http://www.flickr.com/photos/rutlo/4094249840/Creative Commons Attribution License
  • Photo credits: http://www.flickr.com/photos/annahape-gallery/Creative Commons Attribution License
  • Photo credits: http://www.flickr.com/photos/wwarby/2460644803/Creative Commons Attribution License
  • Photo credits: http://www.flickr.com/photos/paalia/3582759194/Creative Commons Attribution License
  • Photo credits: http://www.flickr.com/photos/emilysoo/3863285545/Creative Commons Attribution License
  • Transcript of "Architecting Applications the Microsoft Way"

    1. 1. Architecting Applications the Microsoft Way<br />Clint Edmonson<br />Developer Evangelist<br />Microsoft Corporation<br />
    2. 2. Who the heck needs architecture?<br />
    3. 3.
    4. 4.
    5. 5.
    6. 6.
    7. 7.
    8. 8.
    9. 9.
    10. 10. Architecture<br />“A unifying or coherent form or structure.”<br /> merriam-webster.com<br />
    11. 11. Design<br />“Design, at its most fundamental, is about finding solutions.”<br /> Garr Reynolds<br />
    12. 12. A technique for architecture & design<br />Page 41<br />
    13. 13. 1. Identify architecture objectives<br />Goals based on size, scope, time<br />Complete application<br />Prototype<br />Solving a technical risk<br />Exploring potential options<br />Building shared, reference models<br />Target audience<br />Other architects<br />Developers<br />Testers<br />Operations<br />
    14. 14. 2. Identify key scenarios<br />Define the solution’s boundaries<br />Identify who will impacted by the solution<br />Discover what valuable activities will be automated<br />Uncover constraints that will limit the solution<br />Highlight those that are most important to the success of your application<br />
    15. 15. Brainstorming scope & key scenarios<br />
    16. 16. 3. Create an application overview<br />Determine your application type<br />Web<br />Mobile<br />Rich client<br />RIA<br />Web service<br />Some combination of the above<br />Identify your deployment constraints<br />Determine your relevant technologies<br />Identify important architectural styles<br />
    17. 17. Architecture styles<br />Layered<br />Client/server<br />Component-based<br />Domain driven design <br />Message bus<br />N-Tier<br />Object-oriented<br />Service-oriented<br />This is our architecture toolbox!<br />
    18. 18. 4. Identify key issues<br />Cross-cutting concerns<br />Configuration<br />Security<br />Communication<br />Compression<br />Encryption<br />Logging & instrumentation<br />Validation<br />Error management<br />Quality attributes<br />Run-time performance <br />Scalability<br />Disaster recovery<br />
    19. 19. 5. Define candidate solution(s)<br />Choose an architecturally significant scenario <br />Design out a baseline architecture<br />Prove it out<br />
    20. 20. Common Application Architecture<br />Page 10<br />
    21. 21. Lay(er)ing it all out<br />Describe the application at a high level <br />Identify major components and other functional units of the design and their interdependencies<br />Each layer represents a logical group of projects, namespaces, and/or other artifacts<br />
    22. 22. Layered structure design steps<br />Determine layers you require<br />Determine rules for interaction between layers<br />Identify cross-cutting concerns<br />Determine if you need to collapse layers<br />Choose deployment strategy<br />
    23. 23. Presentation layer<br />UI Components<br />Presentation Layer Logic Components<br />Navigation<br />Error handling<br />Validation<br />
    24. 24. Services layer<br />Authentication<br />Authorization<br />Communication & messaging format<br />Exception handling<br />
    25. 25. Business layer<br />Authentication<br />Authorization<br />Exception handling<br />Logging, auditing, & instrumentation<br />Validation<br />
    26. 26. Data layer<br />Batching<br />Blobs<br />Connections<br />Data format<br />Exception management<br />O/R mapping<br />Transactions<br />Validation<br />
    27. 27. Initial architecture<br />
    28. 28. Physical deployment<br />Visualize the physical structure of a system <br />Executables<br />Libraries<br />Services<br />Focus on components of the system, their relationships, interfaces, and ports<br />Highlight the service behavior that they provide and consume through interfaces<br />
    29. 29. Physical deployment<br />
    30. 30. Grouping layers into assemblies<br />Prefer fewer, larger assemblies<br />Faster load time<br />Reduced working set<br />Better NGEN optimization<br />If several assemblies are always loaded together, consider combining them into one<br />Partition into separate assemblies based on<br />Security control<br />Independent versioning<br />Data access<br />Contributions from disparate sources<br />
    31. 31. Rinse, repeat, refactor…<br />Page 41<br />
    32. 32. Architecture after several iterations<br />
    33. 33. Key architecture principles<br />Separation of Concerns<br />Single Responsibility Principle<br />Principle of Least Knowledge<br />Don’t Repeat Yourself<br />Minimize Upfront Design<br />
    34. 34. Best Practices<br />Minimize upfront design<br />avoid starting more than 1 namespace deep when layering<br />Analyze and refactor at the beginning of each iteration<br />Separate functional areas of concern cleanly<br />Avoid duplicating responsibilities<br />Minimize dependencies between layers<br />Make it obvious where code needs to go!<br />
    35. 35. References<br />Microsoft Application Architecture Guide 2nd Edition<br />by Microsoft Patterns & Practices Group<br />Microsoft .NET: Architecting Application for the Enterprise<br />by Dino Esposito & Andrea Salterello<br />Domain Driven Design<br />by Eric Evans<br />Framework Design Guidelines<br /> by Krzysztof Cwalina & Brad Abrams<br />
    36. 36. Call to action<br />Download the trial<br />Available now on MSDN<br />Team blog:<br />http://blogs.msdn.com/vsarch<br />Stayed tuned to my blog for more…<br />http://www.notsotrivial.net<br />clinted@microsoft.com<br />
    37. 37. Q & A<br />
    38. 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.<br />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.<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×