Your SlideShare is downloading. ×
Architecting Applications the Microsoft Way
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Architecting Applications the Microsoft Way

6,454
views

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 …

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,454
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
115
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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

    • 1. Architecting Applications the Microsoft Way
      Clint Edmonson
      Developer Evangelist
      Microsoft Corporation
    • 2. Who the heck needs architecture?
    • 3.
    • 4.
    • 5.
    • 6.
    • 7.
    • 8.
    • 9.
    • 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.