.NET Application Architecture Guide, 2nd Edition Guide

ApplicationArchitectureGuide

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 560 [warning: Documents this large are best viewed by clicking the View PDF Link!]

• • • • • •
• • • • • • • •
• • • • • • •
• • • • •
MICROSOFT®
APPLICATION
AR C H I T E C T U R E
GU I D E
2nd Edition
ISBN: 9780735627109
Information in this document, including URL and other Internet Web site references,
is subject to change without notice. Unless otherwise noted, the example companies,
organizations, products, domain names, e-mail addresses, logos, people, places,
and events depicted herein are fictitious, and no association with any real company,
organization, product, domain name, e-mail address, logo, person, place, or event
is intended or should be inferred. Complying with all applicable copyright laws is
the responsibility of the user. Without limiting the rights under copyright, no part of
this document may be reproduced, stored in or introduced into a retrieval system,
or transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission
of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other
intellectual property rights covering subject matter in this document. Except as
expressly provided in any written license agreement from Microsoft, the furnishing
of this document does not give you any license to these patents, trademarks, copy-
rights, or other intellectual property.
© 2009 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, MSDN,
Visual Basic, Visual C++, Visual C#, Visual Studio, and Win32 are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries.
The names of actual companies and products mentioned herein may be the trade-
marks of their respective owners.
Contents
Forewords and Preface
Foreword by S. Somasegar ......................................................xxi
Foreword by Scott Guthrie .......................................................xxii
Preface by David Hill ..........................................................xxiii
Introducing the Guide xxvii
Audience ...................................................................xxviii
How to Use This Guide ........................................................xxviii
Feedback and Support ........................................................xxix
Technical Support ..........................................................xxix
Community and Newsgroup Support ...........................................xxix
The Team Who Brought You This Guide ............................................xxx
Contributors and Reviewers ...................................................xxx
Tell Us About Your Success .....................................................xxxi
Software Architecture and Design 1
Chapter 1: What Is Software Architecture? 3
Why Is Architecture Important? ....................................................4
The Goals of Architecture ........................................................5
The Architectural Landscape ...................................................6
The Principles of Architecture Design ...............................................7
Key Architecture Principles .....................................................7
Additional Resources .........................................................8
Chapter 2: Key Principles of Software Architecture 9
Overview ......................................................................9
Key Design Principles ..........................................................11
Key Design Considerations ......................................................14
Determine the Application Type ................................................15
Determine the Deployment Strategy ............................................15
Determine the Appropriate Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Determine the Quality Attributes ...............................................16
Determine the Crosscutting Concerns ...........................................17
.NET Application Architecture Guide, 2nd Edition
iv
Chapter 3: Architectural Patterns and Styles 19
Overview.19
What.Is.an.Architectural.Style?.19
Summary.of.Key.Architectural.Styles..20
Combining.Architectural.Styles.21
Client/Server.Architectural.Style.21
Component-Based.Architectural.Style.23
Domain.Driven.Design.Architectural.Style.                                          25
Layered.Architectural.Style.26
Message.Bus.Architectural.Style................................................. 29
N-Tier./.3-Tier.Architectural.Style.30
Object-Oriented.Architectural.Style.32
Service-Oriented.Architectural.Style.33
Additional.Resources.35
Chapter 4: A Technique for Architecture and Design 37
Overview.37
Inputs,.Outputs,.and.Design.Steps.37
Identify.Architecture.Objectives.39
Scope.and.Time.40
Key.Scenarios.41
Architecturally.Signicant.Use.Cases.41
Application.Overview.42
Relevant.Technologies.43
Whiteboard.Your.Architecture.44
Key.Issues.45
Quality.Attributes..45
Crosscutting.Concerns.46
Designing.for.Issue.Mitigation.46
Candidate.Solutions.48
Baseline.and.Candidate.Architectures.......................................... 49
Architectural.Spikes.49
What.to.Do.Next.50
Reviewing.Your.Architecture.50
Scenario-Based.Evaluations.50
Representing.and.Communicating.Your.Architecture.Design.                           51
Additional.Resources.52
Contents v
Design Fundamentals 53
Chapter 5: Layered Application Guidelines 55
Overview .....................................................................55
Logical Layered Design .........................................................56
Presentation, Business, and Data Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Services and Layers ............................................................58
Services Layer ..............................................................58
Design Steps for a Layered Structure ..............................................60
Step 1 – Choose Your Layering Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Step 2 – Determine the Layers You Require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Step 3 – Decide How to Distribute Layers and Components . . . . . . . . . . . . . . . . . . . . . . . . . 62
Step 4 – Determine If You Need to Collapse Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Step 5 – Determine Rules for Interaction Between Layers . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Step 6 – Identify Cross Cutting Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 7 – Dene the Interfaces between Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 8 – Choose Your Deployment Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 9 – Choose Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 6: Presentation Layer Guidelines 67
Overview .....................................................................67
General Design Considerations ..................................................69
Specic Design Issues ..........................................................70
Caching ...................................................................70
Communication .............................................................71
Composition ................................................................71
Exception Management ......................................................72
Navigation .................................................................73
User Experience ............................................................73
User Interface ..............................................................74
Validation ..................................................................75
Technology Considerations ......................................................75
Mobile Applications ..........................................................75
Rich Client Applications ......................................................76
Rich Internet Applications .....................................................76
Web Applications ............................................................77
Performance Considerations .....................................................77
Design Steps for the Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Relevant Design Patterns .......................................................80
patterns & practices Offerings ...................................................82
Additional Resources ...........................................................82
.NET Application Architecture Guide, 2nd Edition
vi
Chapter 7: Business Layer Guidelines 83
Overview .....................................................................83
General Design Considerations ..................................................86
Specic Design Issues ..........................................................87
Authentication ..............................................................87
Authorization ...............................................................88
Caching ...................................................................88
Coupling and Cohesion .......................................................89
Exception Management ......................................................89
Logging, Auditing, and Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Validation ..................................................................91
Deployment Considerations .....................................................91
Design Steps for the Business Layer ..............................................92
Relevant Design Patterns .......................................................93
patterns & practices Offerings ...................................................94
Additional Resources ...........................................................94
Chapter 8: Data Layer Guidelines 95
Overview .....................................................................95
General Design Considerations ..................................................97
Specic Design Issues ..........................................................99
Batching ..................................................................99
Binary Large Objects ........................................................100
Connections ...............................................................100
Data Format ...............................................................101
Exception Management .....................................................101
Object Relational Mapping ...................................................102
Queries ...................................................................103
Stored Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Stored Procedures vs. Dynamic SQL ...........................................104
Transactions ..............................................................105
Validation ................................................................107
XML .....................................................................107
Technology Considerations .....................................................108
Performance Considerations ....................................................109
Security Considerations ........................................................109
Deployment Considerations ....................................................110
Design Steps for the Data Layer .................................................110
Relevant Design Patterns ......................................................112
Additional Resources ..........................................................113
Contents vii
Chapter 9: Service Layer Guidelines 115
Overview ....................................................................115
Design Considerations .........................................................117
Specic Design Issues .........................................................118
Authentication .............................................................119
Authorization ..............................................................119
Communication ............................................................120
Exception Management .....................................................120
Messaging Channels ........................................................121
Message Construction ......................................................121
Message Endpoint .........................................................122
Message Protection ........................................................122
Message Routing ...........................................................123
Message Transformation ....................................................123
Service Interface ...........................................................124
Validation .................................................................124
REST and SOAP ..............................................................125
Design Considerations for REST ...............................................126
Design Considerations for SOAP ..............................................127
Technology Considerations .....................................................127
Deployment Considerations ....................................................128
Design Steps for the Service Layer ...............................................129
Relevant Design Patterns ......................................................130
Additional Resources ..........................................................133
Chapter 10: Component Guidelines 135
Overview ....................................................................135
General Guidelines for Component Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Layered Component Distribution ................................................136
Presentation Layer Components .................................................138
Services Layer Components ....................................................139
Business Layer Components ....................................................139
Data Layer Components .......................................................141
Crosscutting Components ......................................................142
Relevant Design Patterns ......................................................142
patterns & practices Offerings ..................................................144
Additional Resources ..........................................................144
.NET Application Architecture Guide, 2nd Edition
viii
Chapter 11: Designing Presentation Components 145
Overview ....................................................................145
Step 1 – Understand the UI Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Step 2 – Determine the UI Type Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Step 3 – Choose the UI Technology ..............................................147
Step 4 – Design the Presentation Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
User Interface Components ..................................................150
Presentation Logic Components ..............................................151
Presentation Model Components .............................................152
Step 5 – Determine the Binding Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Step 6 – Determine the Error Handling Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Step 7 – Determine the Validation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
patterns & practices Offerings ..................................................158
Additional Resources ..........................................................158
Chapter 12: Designing Business Components 159
Overview ....................................................................159
Step 1 – Identify Business Components Your Application
Will Use ..................................................................159
Step 2 – Make Key Decisions for Business Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Step 3 – Choose Appropriate Transaction Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Step 4 – Identify How Business Rules Are Handled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Step 5 – Identify Patterns That Fit the Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Additional Resources ..........................................................166
Chapter 13: Designing Business Entities 167
Overview ....................................................................167
Step 1 – Choose the Representation .............................................168
Step 2 – Choose a Design for Business Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Step 3 – Determine Serialization Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Domain Driven Design .........................................................170
Additional Resources ..........................................................172
Chapter 14: Designing Workflow Components 173
Overview ....................................................................173
Step 1 – Identify the Workow Style Using Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Step 2 – Choose an Authoring Mode .............................................174
Step 3 – Determine How Rules Will Be Handled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Step 4 – Choose a Workow Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Step 5 – Design Business Components to Support Workow . . . . . . . . . . . . . . . . . . . . . . . . . 176
Windows Workow Foundation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
BizTalk Server .............................................................177
BizTalk with ESB ...........................................................179
Using Windows Workow Foundation and BizTalk Together . . . . . . . . . . . . . . . . . . . . . . . . .180
Additional Resources ..........................................................180
Contents ix
Chapter 15: Designing Data Components 181
Overview ....................................................................181
Step 1 – Choose a Data Access Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Step 2 – Choose How to Retrieve and Persist Business Objects from the Data Store . . . . . .183
Step 3 –Determine How to Connect to the Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
Connections ...............................................................184
Connection Pooling .........................................................185
Transactions and Concurrency ................................................186
Step 4 – Determine Strategies for Handling Data Source Errors . . . . . . . . . . . . . . . . . . . . . . . 187
Exceptions ................................................................188
Retry Logic ................................................................188
Timeouts .................................................................189
Step 5 – Design Service Agent Objects (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Additional Resources ..........................................................189
Chapter 16: Quality Attributes 191
Overview ....................................................................191
Common Quality Attributes .....................................................192
Availability ................................................................194
Conceptual Integrity ........................................................195
Interoperability ............................................................196
Maintainability .............................................................196
Manageability .............................................................197
Performance ..............................................................198
Reliability .................................................................199
Reusability ................................................................200
Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Security ..................................................................201
Supportability .............................................................202
Testability .................................................................202
User Experience / Usability ..................................................203
Additional Resources ..........................................................204
Chapter 17: Crosscutting Concerns 205
Overview ....................................................................205
General Design Considerations .................................................206
Specic Design Issues .........................................................207
Authentication .............................................................207
Authorization ..............................................................208
Caching ..................................................................209
Communication ............................................................210
Conguration Management ..................................................210
Exception Management .....................................................211
Logging and Instrumentation .................................................212
.NET Application Architecture Guide, 2nd Edition
x
State Management .........................................................213
Validation .................................................................213
Design Steps for Caching ......................................................214
Step 1 – Determine the Data to Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Step 2 – Determine Where to Cache Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Step 3 – Determine the Format of Your Data to Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Step 4 – Determine a Suitable Cache Management Strategy . . . . . . . . . . . . . . . . . . . . . . 216
Step 5 – Determine How to Load the Cache Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Design Steps for Exception Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Step 1 – Identify Exceptions That You Want to Handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Step 2 – Determine Your Exception Detection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Step 3 – Determine Your Exception Propagation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Step 4 – Determine Your Custom Exception Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Step 5 – Determine Appropriate Information to Gather . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Step 6 – Determine Your Exception Logging Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Step 7 – Determine Your Exception Notication Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Step 8 – Determine How to Handle Unhandled Exceptions . . . . . . . . . . . . . . . . . . . . . . . . .222
Design Steps for Validating Input and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Step 1 – Identify your Trust Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Step 2 – Identify Key Scenarios ...............................................223
Step 3 – Determine Where to Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
Step 4 – Identify Validation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Relevant Design Patterns ......................................................224
patterns & practices Solution Assets .............................................225
Additional Resources ..........................................................225
Chapter 18: Communication and Messaging 227
Overview ....................................................................227
General Design Guidelines .....................................................228
Message-Based Communication Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
Asynchronous vs. Synchronous Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
Coupling and Cohesion ......................................................231
Data Formats ..............................................................231
Interoperability ............................................................232
Performance ..............................................................233
State Management .........................................................233
Contract First Design ..........................................................234
Security Considerations ........................................................235
Transport Security ..........................................................235
Message Security ..........................................................235
Technology Options ...........................................................236
WCF Technology Options .....................................................236
ASMX Technology Options ...................................................237
Additional Resources ..........................................................237
Contents xi
Chapter 19: Physical Tiers and Deployment 239
Overview ....................................................................239
Distributed and Nondistributed Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Nondistributed Deployment ..................................................240
Distributed Deployment .....................................................240
Performance and Design Considerations for Distributed Environments . . . . . . . . . . . . . . . 241
Recommendations for Locating Components within a Distributed
Deployment .............................................................242
Distributed Deployment Patterns ................................................243
Client-Server Deployment ....................................................243
n-Tier Deployment ..........................................................244
2-Tier Deployment ..........................................................244
3-Tier Deployment ..........................................................244
4-Tier Deployment ..........................................................245
Web Application Deployment .................................................246
Rich Internet Application Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Rich Client Application Deployment ............................................246
Performance Patterns .........................................................247
Load-balanced Cluster ......................................................247
Afnity and User Sessions ...................................................250
Application Farms ..........................................................250
Reliability Patterns ............................................................250
Failover Cluster ............................................................250
Security Patterns .............................................................252
Impersonation/Delegation ...................................................252
Trusted Subsystem .........................................................253
Multiple Trusted Service Identities .............................................254
Scale Up and Scale Out ........................................................255
Considerations for Scaling Up ................................................255
Designing to Support Scale Out ...............................................256
Design Implications and Tradeoffs .............................................256
Network Infrastructure Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258
Manageability Considerations ...................................................259
Relevant Design Patterns ......................................................260
Additional Resources ..........................................................261
.NET Application Architecture Guide, 2nd Edition
xii
Application Archetypes 263
Chapter 20: Choosing an Application Type 265
Overview ....................................................................265
Application Archetypes Summary ................................................266
Application Type Considerations ..............................................266
Mobile Application Archetype ...................................................268
Rich Client Application Archetype ................................................269
Rich Internet Application Archetype ..............................................271
Service Archetype ............................................................272
Web Application Archetype .....................................................274
Chapter 21: Designing Web Applications 277
Overview ....................................................................277
General Design Considerations .................................................279
Specic Design Issues .........................................................280
Application Request Processing ...............................................280
Authentication .............................................................282
Authorization ..............................................................282
Caching ..................................................................283
Exception Management .....................................................283
Logging and Instrumentation .................................................284
Navigation ................................................................284
Page Layout ..............................................................285
Page Rendering ............................................................286
Session Management .......................................................286
Validation .................................................................287
Design Considerations for Layers ................................................287
Presentation Layer .........................................................287
Business Layer ............................................................288
Data Layer ................................................................288
Service Layer ..............................................................288
Testing and Testability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Technology Considerations .....................................................289
Deployment Considerations ....................................................290
NonDistributed Deployment ..................................................290
Distributed Deployment .....................................................291
Load Balancing ............................................................292
Relevant Design Patterns ......................................................294
Additional Resources ..........................................................296
Contents xiii
Chapter 22: Designing Rich Client Applications 297
Overview ....................................................................297
General Design Considerations .................................................299
Specic Design Issues .........................................................300
Business Layer ............................................................300
Communication ............................................................301
Composition ...............................................................302
Conguration Management ..................................................303
Data Access ...............................................................303
Exception Management .....................................................304
Maintainability .............................................................305
Presentation Layer .........................................................306
State Management .........................................................307
Workow .................................................................307
Security Considerations ........................................................308
Data Handling Considerations ..................................................309
Caching Data ..............................................................309
Data Concurrency ..........................................................310
Data Binding ..............................................................310
Ofine/Occasionally Connected Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Technology Considerations .....................................................312
Deployment Considerations ....................................................313
Stand-alone Deployment ....................................................313
Client/Server Deployment ...................................................313
N-Tier Deployment ..........................................................314
Deployment Technologies ....................................................315
Relevant Design Patterns ......................................................315
Additional Resources ..........................................................317
Chapter 23: Designing Rich Internet Applications 319
Overview ....................................................................319
General Design Considerations .................................................321
Specic Design Issues .........................................................323
Business Layer ............................................................323
Caching ..................................................................324
Communication ............................................................324
Composition ...............................................................325
Data Access ...............................................................326
Exception Management .....................................................326
.NET Application Architecture Guide, 2nd Edition
xiv
Logging ...................................................................327
Media and Graphics ........................................................327
Mobile ...................................................................328
Portability .................................................................328
Presentation ..............................................................329
State Management .........................................................329
Validation .................................................................330
Security Considerations ........................................................330
Data Handling Considerations ..................................................331
Technology Considerations .....................................................332
Deployment Considerations ....................................................334
Installation of the RIA Plug-In .................................................334
Distributed Deployment .....................................................335
Load Balancing ............................................................336
Web Farm Considerations ...................................................337
Relevant Design Patterns ......................................................337
Additional Resources ..........................................................338
Chapter 24: Designing Mobile Applications 339
Overview ....................................................................339
General Design Considerations .................................................341
Specic Design Issues .........................................................342
Authentication and Authorization ..............................................342
Caching ..................................................................343
Communication ............................................................344
Conguration Management ..................................................345
Data Access ...............................................................345
Device Specics ...........................................................346
Exception Management .....................................................347
Logging ...................................................................347
Porting Applications ........................................................348
Power Management ........................................................349
Synchronization ............................................................349
Testing ...................................................................350
User Interface .............................................................350
Validation .................................................................351
Technology Considerations .....................................................352
Microsoft Silverlight for Mobile ................................................352
.NET Compact Framework ...................................................352
Windows Mobile ...........................................................353
Windows Embedded ........................................................354
Deployment Considerations ....................................................355
Relevant Design Patterns ......................................................356
Additional Resources ..........................................................357
Contents xv
Chapter 25: Designing Service Applications 359
Overview ....................................................................359
General Design Considerations .................................................361
Specic Design Issues .........................................................363
Authentication .............................................................364
Authorization ..............................................................364
Business Layer ............................................................364
Communication ............................................................365
Data Layer ................................................................366
Exception Management .....................................................366
Message Construction ......................................................367
Message Endpoint .........................................................367
Message Protection ........................................................368
Message Transformation ....................................................369
Message Exchange Patterns .................................................369
Representational State Transfer ..............................................370
Service Layer ..............................................................371
SOAP ....................................................................372
Validation .................................................................373
Technology Considerations .....................................................373
Deployment Considerations ....................................................374
Relevant Design Patterns ......................................................375
Additional Resources ..........................................................378
Chapter 26: Designing Hosted and Cloud Services 379
Overview ....................................................................379
Cloud Computing ...........................................................379
Common Vocabulary for Hosted and Cloud Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Benets of Cloud Applications ..................................................382
Benets for ISVs and Service Hosts ............................................382
Benets for Enterprise Service Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383
Design Issues ................................................................384
Data Isolation and Sharing ...................................................384
Data Security .............................................................386
Data Storage and Extensibility ................................................387
Identity Management .......................................................389
Multi-tenancy ..............................................................392
On-premises or Off-premises, Build or Buy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393
Performance ..............................................................394
Service Composition ........................................................395
Service Integration .........................................................397
Service Management .......................................................399
Relevant Design Patterns ......................................................400
Additional Resources ..........................................................401
.NET Application Architecture Guide, 2nd Edition
xvi
Chapter 27: Designing Office Business Applications 403
Overview ....................................................................403
Components of an Ofce Business Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .404
Key Scenarios for Ofce Business Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405
Enterprise Content Management .............................................406
Business Intelligence .......................................................407
Unied Messaging ..........................................................407
Common OBA Patterns ........................................................408
Extended Reach Channel ....................................................408
Document Integration .......................................................410
Document Workow ........................................................413
Composite UI ..............................................................414
Data Consolidation (Discovery Navigation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Collaboration ..............................................................417
Notications and Tasks ......................................................417
General Design Considerations .................................................418
Security Considerations ........................................................419
Deployment Considerations ....................................................420
Relevant Design Patterns ......................................................420
Additional Resources ..........................................................422
Chapter 28: Designing SharePoint LOB Applications 423
Overview ....................................................................423
Logical Layers of a SharePoint LOB Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Physical Tier Deployment ....................................................425
Key Scenarios and Features ....................................................426
General Design Considerations .................................................427
Specic Design Issues .........................................................428
Business Data Catalog ......................................................428
Document and Content Storage ...............................................429
Excel Services .............................................................430
InfoPath Form Services ......................................................430
SharePoint Object Model ....................................................431
Web Parts ................................................................431
Workow .................................................................432
Technology Considerations .....................................................433
Deployment Considerations ....................................................433
Relevant Design Patterns ......................................................434
Additional Resources ..........................................................434
Contents xvii
Appendices 435
Appendix A: The Microsoft Application Platform 437
Overview ....................................................................437
Finding Information and Resources ..............................................438
How Microsoft Organizes Technical Information on the Web . . . . . . . . . . . . . . . . . . . . . . . .438
Microsoft Developer Network ................................................439
Microsoft TechNet ..........................................................440
The .NET Framework ..........................................................440
Common Language Runtime ...................................................440
Data Access .................................................................440
Mobile Applications ...........................................................442
Rich Client ..................................................................442
Rich Internet Application .......................................................443
Services ....................................................................443
Workow ....................................................................444
Web Applications .............................................................445
Web Server – Internet Information Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .445
Database Server – SQL Server ..................................................446
Visual Studio Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446
Other Tools and Libraries ......................................................447
patterns & practices Solution Assets ...........................................447
Additional Resources ..........................................................448
Appendix B: Presentation Technology Matrix 449
Overview ....................................................................449
Presentation Technologies Summary .............................................449
Mobile Applications .........................................................449
Rich Client Applications .....................................................450
Rich Internet Applications ....................................................451
Web Applications ...........................................................451
Benets and Considerations Matrix ..............................................452
Mobile Applications .........................................................452
Rich Client Applications .....................................................453
Rich Internet Applications ....................................................454
Web Applications ...........................................................455
Common Scenarios and Solutions ...............................................456
Mobile Applications .........................................................456
Rich Client Applications .....................................................456
Rich Internet Applications ....................................................457
Web Applications ...........................................................458
Additional Resources .........................................................459
.NET Application Architecture Guide, 2nd Edition
xviii
Appendix C: Data Access Technology Matrix 461
Overview ....................................................................461
Data Access Technologies Summary .............................................461
Benets and Considerations Matrix ..............................................463
Object-Relational Data Access ................................................463
Disconnected and Ofine ....................................................464
SOA/Service Scenarios ......................................................464
N-Tier and General .........................................................465
General Recommendations .....................................................466
Common Scenarios and Solutions ...............................................467
LINQ to SQL Considerations ....................................................468
Mobile Considerations .........................................................469
Additional Resources .........................................................469
Appendix D: Integration Technology Matrix 471
Overview ....................................................................471
Integration Technologies Summary ..............................................471
Benets and Considerations Matrix ..............................................472
Common Scenarios and Solutions ...............................................474
Additional Resources ..........................................................475
Appendix E: Workflow Technology Matrix 477
Overview ....................................................................477
Workow Technologies Summary ................................................477
Human Workow vs. System Workow ............................................478
Benets and Considerations Matrix ..............................................478
Common Scenarios and Solutions ...............................................480
Additional Resources ..........................................................481
Appendix F: patterns & practices Enterprise Library 483
Overview ....................................................................483
Goals of Enterprise Library .....................................................483
What’s Included in Enterprise Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Application Blocks ..........................................................485
Caching Application Block ......................................................486
Key Scenarios .............................................................486
When to Use ..............................................................486
Considerations ............................................................487
Cryptography Application Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Key Scenarios .............................................................488
When to Use ..............................................................488
Considerations ............................................................488
Contents xix
Data Access Application Block ..................................................489
Key Scenarios .............................................................489
When to Use ..............................................................489
Considerations ............................................................489
Exception Handling Application Block ............................................490
Key Scenarios .............................................................490
When to Use ..............................................................490
Logging Application Block ......................................................491
Key Scenarios .............................................................491
When to Use ..............................................................491
Considerations ............................................................492
Policy Injection Application Block ................................................492
Key Scenarios .............................................................492
When to Use ..............................................................493
Considerations ............................................................493
Security Application Block ......................................................494
Key Scenarios .............................................................494
When to Use ..............................................................494
Considerations ............................................................494
Unity Application Block ........................................................495
Key Scenarios .............................................................495
When to Use ..............................................................495
Considerations ............................................................495
Validation Application Block ....................................................496
Key Scenarios .............................................................496
When to Use ..............................................................496
Considerations ............................................................496
Additional Resources ..........................................................497
Appendix G: patterns & practices Pattern Catalog 499
Composite Application Guidance for WPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499
Data Movement Patterns ......................................................500
Enterprise Solution Patterns ....................................................501
Integration Patterns ...........................................................504
Web Services Security Patterns .................................................506
Additional Resources ..........................................................507
Index 509
Foreword by S. Somasegar
In using our own technologies to build Microsoft products, and working with cus-
tomers and partners every day, we have developed practical guidance on applying
best practices for application architecture and design patterns and principles
using our technologies. This guidance is valuable to both the developer and to
the solution architect. We have built the Microsoft Application Architecture Guide to
consolidate guidance that we have gathered from our internal practices, external
experts, customers, and others in the community in order to share it with you.
The purpose of the guide is to help solution architects and developers to design and
build applications on the Microsoft platform that are more effective, to support key
decision making at the early stages of a new project, as well as providing topic-specific
content to help architects and developers improve their existing solutions. This guidance
incorporates the contributions and reviews from more than 25 external experts and
customers.
By thinking about solutions in terms of architectural patterns and principles, quality
attributes, and crosscutting concerns, you can very quickly determine a baseline appli-
cation architecture and the relevant technologies, patterns, and guidance assets that
will help you build your solution. You can then use the guide to identify key areas of
your application architecture so you can refine them for your scenario.
The guide includes reference application architectures for common application types,
such as Web, rich client, RIA, mobile, and services applications; guidelines for quality
attributes and crosscutting concerns; and guidelines on design approaches that can
help you to design and refine your solution architecture.
We are confident that the Microsoft Application Architecture Guide 2nd Edition will help
you choose the right architecture, the right technologies, and the relevant patterns
that will help you make more effective design decisions.
Sincerely,
S. Somasegar
Senior Vice President of Developer Division
Microsoft
Contents
Foreword by S. Somasegar xxi
Foreword by Scott Guthrie xxii
.NET Application Architecture Guide, 2nd Edition
xxii
Foreword by Scott Guthrie
Application architecture is a challenging topic, as evidenced by the wide variety of
books, articles, and white papers on the subject. It is still too hard for developers and
architects to understand architecture and best practice design for the Microsoft plat-
form. The original Application Architecture for .NET: Designing Applications and Services
guide did a great job of covering this topic, but it was written in 2002.
To deal with the many technology additions since then, J. D. Meier, David Hill,
and their team from Microsoft patterns & practices have created a new application
architecture guide to provide insightful guidance for designing applications and
services that run on the Microsoft platform based on the latest best practices and
technologies. The outcome is Microsoft Application Architecture Guide 2nd Edition, a
guide targeted to help solution architects and developers design effective applica-
tions on the Microsoft platform. While the guide provides an overview of the .NET
Framework, the Microsoft platform, and the main technologies and capabilities
within them, it also provides platform-independent, pattern-oriented, principles-
based guidance that will help you design your applications on a solid foundation.
The guide is based on a number of key architecture and design principles that provide
structure. It includes guidelines for identifying and dealing with key engineering
decisions, and an explanation of the quality attributes, crosscutting concerns, and
capabilities that shape your application architecture; such as performance, security,
scalability, manageability, deployment, communication, and more.
The guide also describes, at a meta-level, the tiers and layers that a solution architect
should consider. Each tier/layer is described in terms of its focus, function, capabilities,
common design patterns, and technologies. Using these as a backdrop, the guide
then overlays relevant principles, patterns, and practices. Finally, the guide provides
canonical application archetypes to illustrate common application types. Each
archetype is described in terms of the target scenarios, technologies, patterns, and
infrastructure it contains.
The guidance as a whole is based on the combined experience and knowledge of
Microsoft experts, Microsoft partners, customers, and others in the community. It
will help you understand our platform, choose the right architecture and the right
technologies, and build applications using proven practices and lessons learned.
Sincerely,
Scott Guthrie
Corporate Vice President of .NET Developer Platform
Microsoft
Preface by David Hill
There is an old joke, told amongst mischievous developers, that in order to be
considered an architect you just need to answer every technical question with “it
depends”—Q: What’s the best way to implement authentication and authorization in
my solution? —A: It depends; Q: How should I implement my data access layer?—A:
It depends; Q: Which technology should I use for my solution’s UI?—A: It depends.
Q: How can I make my application scalable?—A: It depends. You get the general idea.
The truth is, of course, that it really does depend. Ultimately, every solution is
different and there are many factors, both technical and non-technical, that can
significantly affect the architecture and design of a solution at both the small and
the large scales. The role of the developer and solution architect is to balance the
(frequently contradictory) requirements and constraints imposed by the business,
the end user, the organization’s IT environment and management infrastructure, the
economic environment, and of course the technologies and tools that are used to
build the solution.
And, to make life really interesting, these requirements and constraints are constantly
evolving as new opportunities arise or as new demands are imposed on the system.
Changes to business rules or the emergence of new business areas can affect both new
and existing applications. Over time, users expect richer, more consistent and more
highly integrated user experiences. New compliance requirements might emerge. Or
new IT infrastructure technologies might appear that can reduce costs or improve
availability or scalability. And, of course new technologies, frameworks, and tools are
being released all the time with promises to reduce development costs, or to enable
scenarios that were previously difficult to implement.
Clearly, making sense of all of this and at the same time delivering an effective solu-
tion on budget and to schedule is not an easy task. It requires that the developer or
solution architect have to account for a whole host of competing and overlapping
factors (some of which are non-technical) and strike a pragmatic balance between
them all. Trying to account for too many factors can result in over-engineered,
complex solutions that take a long time to build and nevertheless fail to deliver
on promises of improved longevity or flexibility. On the other hand, consideration
of too few factors can result in constrained, inflexible, and improvised solutions that
are difficult to evolve or that do not scale well. In other words, developers and solu-
tion architects often have to walk the path between a “golden solution” on the one
hand, and a “point-in-time solution” on the other.
Contents
Preface by David Hill xxiii
.NET Application Architecture Guide, 2nd Edition
xxiv
This, to me, is what application architecture is all about—it’s about using today’s
tools and technologies to create as much business value as possible whilst keeping
one eye on the requirements and constraints imposed by the business today, and one
eye looking to tomorrow to maximize ongoing value through scalability, flexibility
and maintainability. A good understanding of architectural principles and patterns
allows the developer or solution architect to understand and factor into the overall
design process the important design issues that can have a big impact on the overall
success of their solution. Armed with this knowledge, they can make more informed
decisions, better balance competing or overlapping requirements and constraints,
and make sure that the solution not only meets or exceeds its business goals but it
does so in way that is cost effective and scalable, maintainable and flexible.
You’ll notice that I refer to both developers and solution architects. I believe that
both can benefit greatly from a solid understanding of the architectural patterns
and principles outlined in this guide. Some might argue that the implementation
details are less important than the overall design. In my experience this is not the
case. Small decisions accumulate over time. Implementation-level details can have
a very large impact on the overall solution architecture and on its scalability, main-
tainability, and flexibility, so a solid understanding by both developers and solution
architects is essential. In addition, a shared understanding leads to better communi-
cation between developers and architects, which is a good thing.
This guide aims to provide an overview of the application architecture and design
principles and patterns that will help you make better decisions and build more
successful solutions. The guide is structured in a way that allows you to read it
from start to finish, or use as a reference resource so you can jump directly to the
most relevant sections. The first half of the guide is focused on generally applicable
architecture and design principles and apply to any type of solution. The last half
is focused on common application types—such as Web applications, rich client
application, or mobile applications—and describes the typical architecture and key
design considerations for each. It’s likely that your particular solution won’t map
directly to these, but they can serve to provide a baseline architecture that you can
take and evolve for your particular situation. The guide provides advice on how to
identify the key elements of your architecture so you can refine it over time.
There is a particular focus throughout the guide on developing solutions on the
Microsoft platform with the .NET Framework so the guide contains references to
articles and resources that provide details on relevant technologies and tools. You’ll
find though that the underlying principles and patterns are generally applicable to
any platform. It is also worth noting that the guide is not meant to be a complete and
comprehensive reference to every aspect of application architecture and design—that
would require either a much larger guide, or multiple volumes—so the guide aims to
provide a pragmatic overview of the most important topics along with links to more
detailed guidance or in-depth material.
Preface xxv
The field of application architecture and design is dynamic and constantly evolving. The
foundations on which successful solutions have been built in the past will continue
to serve us well into the foreseeable future, but we should also expect that the pace
of innovation, in both technologies and new design approaches, will not decrease.
The Microsoft platform and the .NET Framework and the range of technologies and
scenarios that they support are both deep and wide, and getting deeper and wider
all the time. On the other hand, we don’t need to wait for what might be. We can
build compelling valuable solutions right now, and hopefully this guide will help
you do just that.
David Hill
patterns and practices
September 2009
Introducing the Guide
The goal of this guide is to help developers and solution architects build effective,
high quality applications on the Microsoft platform and the .NET Framework more
quickly and with less risk by leveraging tried and trusted architecture and design
principles and patterns.
The guide provides an overview of the underlying principles and patterns that provide
a solid foundation for good application architecture and design. On top of this founda-
tion, the guide provides generally applicable guidance for partitioning an application’s
functionality into layers, components, and services. It goes on to provide guidance on
identifying and addressing the key design characteristics of the solution and the key
quality attributes (such as performance, security, and scalability) and crosscutting
concerns (such as caching and logging). The guide builds still further and provides
guidance that is more specific on the architecture and design of the most common
application types, such as Web, rich Internet applications (RIA), rich client, services,
and mobile applications.
The guidance is presented in parts that correspond to major architecture and design
focus points. It is designed to be used as a reference resource, or it can be read from
beginning to end.
The guide will help you to:
l Understand the underlying architecture and design principles and patterns for
developing successful solutions on the Microsoft platform.
l Identify appropriate strategies and design patterns that will help you design your
solution’s layers, components, and services.
l Identify and address the key engineering decision points for your solution.
l Identify and address the key quality attributes and crosscutting concerns for your
solution.
l Choose the right technologies for your solution.
l Create a candidate baseline architecture for your solution.
l Identify patterns & practices solution assets and further guidance that will help
you to implement your solution.
Note that while the guide is extensive, it is should not be considered a complete and
comprehensive treatise on the field of application architecture and design. The guide
is intended to serve as a practical and convenient overview of and reference to the
general principles of architecture and design on the Microsoft platform and the .NET
Framework.
Contents
Introducing the Guide xxvii
.NET Application Architecture Guide, 2nd Edition
xxviii
In particular, the guide does not try to provide a definitive or authoritative solution
architecture for any particular scenario. Rather, it provides a concise overview of the
principles and patterns that underpin good architecture and design, and highlights
and provides recommendations for some of the most important issues you might
encounter.
The bulk of the guide is technology-agnostic and principled-based, and can be applied
to any platform or technology. However, we have added specific Microsoft and .NET
Framework technology considerations where we think it helps you to choose amongst
available technologies, or to make the most of them in a particular situation.
Audience
This guide is primarily written for developers and solution architects who are looking
for guidance on architecting and designing applications on the Microsoft platform and
the .NET Framework.
However, this guide will benefit any technologist who is generally interested in the
field of application architecture and design, wishes to understand the underlying
patterns and principles behind good application design on the .Microsoft platform or
the .NET Framework, or is new to the Microsoft platform or the .NET Framework.
How to Use This Guide
This guide is not a step-by-step tutorial for application architecture and design, but
rather an overview and a reference. The guide is divided into four main sections,
each containing a number of chapters:
l The first section of the guide, “Software Architecture and Design,” provides a
summary of the underlying principles and patterns that provide the founda-
tion for good application architecture and design and a suggested approach for
creating your architecture design. If you are using the guide to learn about the
fundamentals of application architecture, start with this section and then work
through the remaining parts to learn about layered design, components, quality
attributes, crosscutting concerns, communication, deployment, and common
application types.
l The second section of the guide, “Design Fundamentals,” provides generally
applicable guidance for designing a solution’s layers, components, and services;
and guidance on addressing quality attributes and crosscutting concerns. It also
covers communication and deployment topics. If you want to learn about the
layered approach to application architecture and design, or the design of specific
components and services, start with this section and then explore the following
sections to see how to take account of quality attributes and how to design a
physical deployment strategy.
Introduction xxix
l The third section of the guide, “Application Archetypes,” provides specific guidance
on the architecture and design of typical application types, such as Web, RIA, rich
client, mobile, and services applications. If you have some prior experience with
application architecture and design and want to learn about the architecture and
major design features of common types of application and the specific guidance for
each type, start with this section and then use the remaining sections to expand and
verify your knowledge.
l Finally, the Appendices provide an overview of the Microsoft platform and
.NET Framework technologies and their capabilities. This section also provides
a summary of common design patterns, and references to additional resources
and materials. If you are new to the .NET Framework, or want to learn about the
technologies available on the Microsoft platform, use this section to get an over-
view of the .NET Framework and platform services, see the major technology
matrices, and read descriptions of patterns & practices assets such as Enterprise
Library and the patterns & practices design pattern library.
Depending on your experience and requirements, you can refer directly to the
specific section(s) that best address your needs. Alternatively, if you are looking for
an extensive overview of design and architecture on the Microsoft platform and the
.NET Framework, you can read the guide from start to finish. It will help you to
understand the architecture and design approach. You can work the guidance into
your application development life cycle and processes, and use it as a training tool.
Feedback and Support
We have made every effort to ensure the accuracy of this guide. However, we welcome
feedback on any topics it contains. This includes technical issues specific to the recom-
mendations, usefulness and usability issues, and writing and editing issues. To more
easily access the various Web resources, see the online version of the bibliography at:
http://www.microsoft.com/architectureguide.
If you have comments on this guide, please visit the Application Architecture Guide
community site at http://www.codeplex.com/AppArchGuide.
Technical Support
Technical support for the Microsoft products and technologies referenced in this
guidance is provided by Microsoft Product Support Services (PSS). For product
support information, please visit the Microsoft Product Support Web site at:
http://support.microsoft.com.
Community and Newsgroup Support
You can also obtain community support, discuss this guide, and provide feedback by
visiting the Microsoft MSDN® Newsgroups site at http://msdn.microsoft.com/en-us/
subscriptions/aa974230.aspx.
.NET Application Architecture Guide, 2nd Edition
xxx
The Team Who Brought You This Guide
This guide was produced by the following .NET architecture and development
specialists:
l J.D. Meier
l David Hill
l Alex Homer
l Jason Taylor
l Prashant Bansode
l Lonnie Wall
l Rob Boucher Jr.
l Akshay Bogawat
Contributors and Reviewers
Many thanks to the contributors and reviewers:
l Test Team. Rohit Sharma; Praveen Rangarajan
l Edit Team. Dennis Rea
l External Contributors and Reviewers. Adwait Ullal; Andy Eunson; Brian Sletten;
Christian Weyer; David Guimbellot; David Ing; David Weller; David Sussman;
Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller;
John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert;
Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi
Dahan; Oren Eini aka Ayende Rahien; Gregory Young
l Microsoft Contributors and Reviewers. Ade Miller; Amit Chopra; Anna Liu;
Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley
Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan;
David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov;
Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk;
Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake;
Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader;
Kashinath TR; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu;
Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker;
Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro;
Pat Helland; Phil Haack; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger;
Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath
Vasireddy; Tom Hollander; Vijaya Janakiraman; Wojtek Kozaczynski
Introduction xxxi
Tell Us About Your Success
If this guide helps you, we would like to know. Tell us by writing a short summary
of the problems you faced and how this guide helped you out. Submit your sum-
mary by e-mail to MyStory@Microsoft.com.
Software Architecture and Design
This section of the guide contains a series of topics that will help you to understand
the fundamentals of architecture and design. It starts by describing what is software
architecture is, why is it important. It discusses the general issues you must consider,
such as requirements and constraints and the intersection between the user, the
business, and the system on which the application will run. This is followed by a
description of the key design principles, and the architectural patterns and styles
in common use today. Finally, this section provides an insight into the approach
you should follow when designing your architecture. For more information, see
the following chapters:
l Chapter 1, “What is Software Architecture?”
l Chapter 2, “Key Principles of Software Architecture”
l Chapter 3, “Architectural Patterns and Styles”
l Chapter 4, “A Technique for Architecture and Design”
Contents
Software Architecture and Design 1
1
What Is Software Architecture?
Software application architecture is the process of defining a structured solution that
meets all of the technical and operational requirements, while optimizing common
quality attributes such as performance, security, and manageability. It involves a
series of decisions based on a wide range of factors, and each of these decisions can
have considerable impact on the quality, performance, maintainability, and overall
success of the application.
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined
a definition of architecture based on work by Mary Shaw and David Garlan (Shaw
and Garlan 1996). Their definition is:
“Software architecture encompasses the set of significant decisions about the
organization of a software system including the selection of the structural
elements and their interfaces by which the system is composed; behavior as
specified in collaboration among those elements; composition of these structural
and behavioral elements into larger subsystems; and an architectural style
that guides this organization. Software architecture also involves functionality,
usability, resilience, performance, reuse, comprehensibility, economic and
technology constraints, tradeoffs and aesthetic concerns.”
In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common
recurring themes when explaining architecture. He identifies these themes as:
“The highest-level breakdown of a system into its parts; the decisions that are
hard to change; there are multiple architectures in a system; what is architecturally
significant can change over a system’s lifetime; and, in the end, architecture boils
down to whatever the important stuff is.”
[http://www.pearsonhighered.com/educator/academic/product/
0,3110,0321127420,00.html]
Contents
1 3
What Is Software Architecture? 3
Why Is Architecture Important? ....................................................4
The Goals of Architecture ........................................................5
The Architectural Landscape ...................................................6
The Principles of Architecture Design ...............................................7
Key Architecture Principles .....................................................7
Additional Resources .........................................................8
.NET Application Architecture Guide, 2nd Edition
4
In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define
architecture as follows:
“The software architecture of a program or computing system is the structure or
structures of the system, which comprise software elements, the externally visible
properties of those elements, and the relationships among them. Architecture is
concerned with the public side of interfaces; private details of elements—details
having to do solely with internal implementation—are not architectural.”
[http://www.aw-bc.com/catalog/academic/product/0,4096,0321154959,00.html]
Why Is Architecture Important?
Like any other complex structure, software must be built on a solid foundation.
Failing to consider key scenarios, failing to design for common problems, or failing
to appreciate the long term consequences of key decisions can put your application
at risk. Modern tools and platforms help to simplify the task of building applica-
tions, but they do not replace the need to design your application carefully, based
on your specific scenarios and requirements. The risks exposed by poor architecture
include software that is unstable, is unable to support existing or future business
requirements, or is difficult to deploy or manage in a production environment.
Systems should be designed with consideration for the user, the system (the IT
infrastructure), and the business goals. For each of these areas, you should outline
key scenarios and identify important quality attributes (for example, reliability
or scalability) and key areas of satisfaction and dissatisfaction. Where possible,
develop and consider metrics that measure success in each of these areas.
8VHU %XVLQHVV
6\VWHP
Figure 1
User, business, and system goals
Chapter 1: What Is Software Architecture? 5
Tradeoffs are likely, and a balance must often be found between competing require-
ments across these three areas. For example, the overall user experience of the solution
is very often a function of the business and the IT infrastructure, and changes in one or
the other can significantly affect the resulting user experience. Similarly, changes in the
user experience requirements can have significant impact on the business and IT infra-
structure requirements. Performance might be a major user and business goal, but the
system administrator may not be able to invest in the hardware required to meet that
goal 100 percent of the time. A balance point might be to meet the goal only 80 percent
of the time.
Architecture focuses on how the major elements and components within an applica-
tion are used by, or interact with, other major elements and components within the
application. The selection of data structures and algorithms or the implementation
details of individual components are design concerns. Architecture and design con-
cerns very often overlap. Rather than use hard and fast rules to distinguish between
architecture and design, it makes sense to combine these two areas. In some cases,
decisions are clearly more architectural in nature. In other cases, the decisions are
more about design, and how they help you to realize that architecture.
By following the processes described in this guide, and using the information it
contains, you will be able to construct architectural solutions that address all of
the relevant concerns, can be deployed on your chosen infrastructure, and provide
results that meet the original aims and objectives.
Consider the following high level concerns when thinking about software architecture:
l How will the users be using the application?
l How will the application be deployed into production and managed?
l What are the quality attribute requirements for the application, such as security,
performance, concurrency, internationalization, and configuration?
l How can the application be designed to be flexible and maintainable over time?
l What are the architectural trends that might impact your application now or after
it has been deployed?
The Goals of Architecture
Application architecture seeks to build a bridge between business requirements
and technical requirements by understanding use cases, and then finding ways to
implement those use cases in the software. The goal of architecture is to identify the
requirements that affect the structure of the application. Good architecture reduces
the business risks associated with building a technical solution. A good design is
sufficiently flexible to be able to handle the natural drift that will occur over time
.NET Application Architecture Guide, 2nd Edition
6
in hardware and software technology, as well as in user scenarios and requirements.
An architect must consider the overall effect of design decisions, the inherent trade-
offs between quality attributes (such as performance and security), and the tradeoffs
required to address user, system, and business requirements.
Keep in mind that the architecture should:
l Expose the structure of the system but hide the implementation details.
l Realize all of the use cases and scenarios.
l Try to address the requirements of various stakeholders.
l Handle both functional and quality requirements.
The Architectural Landscape
It is important to understand the key forces that are shaping architectural decisions
today, and which will change how architectural decisions are made in the future.
These key forces are driven by user demand, as well as by business demand for
faster results, better support for varying work styles and workflows, and improved
adaptability of software design.
Consider the following key trends:
l User empowerment. A design that supports user empowerment is flexible,
configurable, and focused on the user experience. Design your application with
appropriate levels of user personalization and options in mind. Allow the user to
define how they interact with your application instead of dictating to them, but do
not overload them with unnecessary options and settings that can lead to confu-
sion. Understand the key scenarios and make them as simple as possible; make it
easy to find information and use the application.
l Market maturity. Take advantage of market maturity by taking advantage of
existing platform and technology options. Build on higher level application
frameworks where it makes sense, so that you can focus on what is uniquely
valuable in your application rather than recreating something that already exists
and can be reused. Use patterns that provide rich sources of proven solutions for
common problems.
l Flexible design. Increasingly, flexible designs take advantage of loose coupling to
allow reuse and to improve maintainability. Pluggable designs allow you to provide
post-deployment extensibility. You can also take advantage of service orientation
techniques such as SOA to provide interoperability with other systems.
l Future trends. When building your architecture, understand the future trends
that might affect your design after deployment. For example, consider trends in
rich UI and media, composition models such as mashups, increasing network
bandwidth and availability, increasing use of mobile devices, continued improve-
ment in hardware performance, interest in community and personal publishing
models, the rise of cloud-based computing, and remote operation.
Chapter 1: What Is Software Architecture? 7
The Principles of Architecture Design
Current thinking on architecture assumes that your design will evolve over time
and that you cannot know everything you need to know up front in order to fully
architect your system. Your design will generally need to evolve during the imple-
mentation stages of the application as you learn more, and as you test the design
against real world requirements. Create your architecture with this evolution in
mind so that it will be able to adapt to requirements that are not fully known at
the start of the design process.
Consider the following questions as you create an architectural design:
l What are the foundational parts of the architecture that represent the greatest risk
if you get them wrong?
l What are the parts of the architecture that are most likely to change, or whose
design you can delay until later with little impact?
l What are your key assumptions, and how will you test them?
l What conditions may require you to refactor the design?
Do not attempt to over engineer the architecture, and do not make assumptions that
you cannot verify. Instead, keep your options open for future change. There will be
aspects of your design that you must fix early in the process, which may represent
significant cost if redesign is required. Identify these areas quickly and invest the
time necessary to get them right.
Key Architecture Principles
Consider the following key principles when designing your architecture:
l Build to change instead of building to last. Consider how the application may
need to change over time to address new requirements and challenges, and build
in the flexibility to support this.
l Model to analyze and reduce risk. Use design tools, modeling systems such as
Unified Modeling Language (UML), and visualizations where appropriate to help
you capture requirements and architectural and design decisions, and to analyze
their impact. However, do not formalize the model to the extent that it suppresses
the capability to iterate and adapt the design easily.
l Use models and visualizations as a communication and collaboration tool.
Efficient communication of the design, the decisions you make, and ongoing
changes to the design, is critical to good architecture. Use models, views, and
other visualizations of the architecture to communicate and share your design
efficiently with all the stakeholders, and to enable rapid communication of
changes to the design.
.NET Application Architecture Guide, 2nd Edition
8
l Identify key engineering decisions. Use the information in this guide to under-
stand the key engineering decisions and the areas where mistakes are most often
made. Invest in getting these key decisions right the first time so that the design is
more flexible and less likely to be broken by changes.
Consider using an incremental and iterative approach to refining your architecture.
Start with a baseline architecture to get the big picture right, and then evolve can-
didate architectures as you iteratively test and improve your architecture. Do not
try to get it all right the first time—design just as much as you can in order to start
testing the design against requirements and assumptions. Iteratively add details to
the design over multiple passes to make sure that you get the big decisions right
first, and then focus on the details. A common pitfall is to dive into the details too
quickly and get the big decisions wrong by making incorrect assumptions, or by
failing to evaluate your architecture effectively. When testing your architecture,
consider the following questions:
l What assumptions have I made in this architecture?
l What explicit or implied requirements is this architecture meeting?
l What are the key risks with this architectural approach?
l What countermeasures are in place to mitigate key risks?
l In what ways is this architecture an improvement over the baseline or the last
candidate architecture?
For more information about the key principles of software architecture design, see
Chapter 2, “Key Principles of Software Architecture.”
For information about the incremental and iterative approach to architecture, baseline
and candidate architectures, and representing and communicating the design, see
Chapter 4, “A Technique for Architecture and Design.”
Additional Resources
Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2nd ed.
Addison-Wesley Professional, 2003.
Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
2
Key Principles of Software
Architecture
Overview
In this chapter, you will learn about the key design principles and guidelines for
software architecture. Software architecture is often described as the organization
or structure of a system, where the system represents a collection of components
that accomplish a specific function or set of functions. In other words, architecture
is focused on organizing components to support specific functionality. This orga-
nization of functionality is often referred to as grouping components into “areas of
concern.” Figure 1 illustrates common application architecture with components
grouped by different areas of concern.
Contents
2 9
Key Principles of Software
Architecture 9
Overview ......................................................................9
Key Design Principles ..........................................................11
Key Design Considerations ......................................................14
Determine the Application Type ................................................15
Determine the Deployment Strategy ............................................15
Determine the Appropriate Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Determine the Quality Attributes ...............................................16
Determine the Crosscutting Concerns ...........................................17
.NET Application Architecture Guide, 2nd Edition
10
8,&RPSRQHQWV
6HUYLFH,QWHUIDFHV 0HVVDJH7\SHV
3UHVHQWDWLRQ/RJLF
&RPSRQHQWV
%XVLQHVV
:RUNIORZ
%XVLQHVV
&RPSRQHQWV
%XVLQHVV
(QWLWLHV
'DWD$FFHVV
&RPSRQHQWV
'DWD+HOSHUV
8WLOLWLHV
6HUYLFH
$JHQWV
$SSOLFDWLRQ)DoDGH
'DWD
6RXUFHV 6HUYLFHV
35(6(17$7,21
/$<(5
86(56
(;7(51$/6<67(06
6(59,&(6
/$<(5
%86,1(66
/$<(5
'$7$
/$<(5
6HUYLFH&RQVXPHUV
&RPPXQLFDWLRQ
2SHUDWLRQDO0DQDJHPHQW
6HFXULW\
&5266&877,1*
Figure 1
Common application architecture
In addition to the grouping of components, other areas of concern focus on interaction
between the components and how different components work together. The guide-
lines in this chapter examine different areas of concern that you should consider when
designing the architecture of your application.
Chapter 2: Key Principles of Software Architecture 11
Key Design Principles
When getting started with your design, keep in mind the key principles that will
help you to create an architecture that adheres to proven principles, minimizes costs
and maintenance requirements, and promotes usability and extendibility. The key
principles are:
l Separation of concerns. Divide your application into distinct features with as
little overlap in functionality as possible. The important factor is minimization of
interaction points to achieve high cohesion and low coupling. However, separating
functionality at the wrong boundaries can result in high coupling and complexity
between features even though the contained functionality within a feature does not
significantly overlap.
l Single Responsibility principle. Each component or module should be responsible
for only a specific feature or functionality, or aggregation of cohesive functionality.
l Principle of Least Knowledge (also known as the Law of Demeter or LoD). A
component or object should not know about internal details of other components
or objects.
l Don’t repeat yourself (DRY). You should only need to specify intent in one place.
For example, in terms of application design, specific functionality should be imple-
mented in only one component; the functionality should not be duplicated in any
other component.
l Minimize upfront design. Only design what is necessary. In some cases, you may
require upfront comprehensive design and testing if the cost of development or a
failure in the design is very high. In other cases, especially for agile development,
you can avoid big design upfront (BDUF). If your application requirements are
unclear, or if there is a possibility of the design evolving over time, avoid making
a large design effort prematurely. This principle is sometimes known as YAGNI
("You ain’t gonna need it").
When designing an application or system, the goal of a software architect is to
minimize the complexity by separating the design into different areas of concern.
For example, the user interface (UI), business processing, and data access all repre-
sent different areas of concern. Within each area, the components you design should
focus on that specific area and should not mix code from other areas of concern. For
example, UI processing components should not include code that directly accesses a
data source, but instead should use either business components or data access com-
ponents to retrieve data.
However, you must also make a cost/value determination on the investment you
make for an application. In some cases, you may need to simplify the structure to
allow, for example, UI data binding to a result set. In general, try to consider the
functional boundaries from a business viewpoint as well. The following high level
guidelines will help you to consider the wide range of factors that can affect the ease
of designing, implementing, deploying, testing, and maintaining your application.
.NET Application Architecture Guide, 2nd Edition
12
Design Practices
l Keep design patterns consistent within each layer. Within a logical layer,
where possible, the design of components should be consistent for a particular
operation. For example, if you choose to use the Table Data Gateway pattern
to create an object that acts as a gateway to tables or views in a database, you
should not include another pattern such as Repository, which uses a different
paradigm for accessing data and initializing business entities. However, you
may need to use different patterns for tasks in a layer that have a large variation
in requirements, such as an application that contains business transaction and
reporting functionality.
l Do not duplicate functionality within an application. There should be only one
component providing a specific functionality—this functionality should not be
duplicated in any other component. This makes your components cohesive and
makes it easier to optimize the components if a specific feature or functionality
changes. Duplication of functionality within an application can make it difficult
to implement changes, decrease clarity, and introduce potential inconsistencies.
l Prefer composition to inheritance. Wherever possible, use composition over
inheritance when reusing functionality because inheritance increases the depen-
dency between parent and child classes, thereby limiting the reuse of child classes.
This also reduces the inheritance hierarchies, which can become very difficult to
deal with.
l Establish a coding style and naming convention for development. Check to see
if the organization has established coding style and naming standards. If not, you
should establish common standards. This provides a consistent model that makes
it easier for team members to review code they did not write, which leads to better
maintainability.
l Maintain system quality using automated QA techniques during development.
Use unit testing and other automated Quality Analysis techniques, such as
dependency analysis and static code analysis, during development. Define clear
behavioral and performance metrics for components and sub-systems, and use
automated QA tools during the build process to ensure that local design or
implementation decisions do not adversely affect the overall system quality.
l Consider the operation of your application. Determine what metrics and opera-
tional data are required by the IT infrastructure to ensure the efficient deployment
and operation of your application. Designing your application’s components and
sub-systems with a clear understanding of their individual operational require-
ments will significantly ease overall deployment and operation. Use automated
QA tools during development to ensure that the correct operational data is pro-
vided by your application’s components and sub-systems.
Chapter 2: Key Principles of Software Architecture 13
Application Layers
l Separate the areas of concern. Break your application into distinct features that
overlap in functionality as little as possible. The main benefit of this approach is
that a feature or functionality can be optimized independently of other features or
functionality. In addition, if one feature fails, it will not cause other features to fail
as well, and they can run independently of one another. This approach also helps
to make the application easier to understand and design, and facilitates manage-
ment of complex interdependent systems.
l Be explicit about how layers communicate with each other. Allowing every
layer in an application to communicate with or have dependencies upon all of the
other layers will result in a solution that is more challenging to understand and
manage. Make explicit decisions about the dependencies between layers and the
data flow between them.
l Use abstraction to implement loose coupling between layers. This can be accom-
plished by defining interface components such as a façade with well known inputs
and outputs that translate requests into a format understood by components within
the layer. In addition, you can also use Interface types or abstract base classes to
define a common interface or shared abstraction (dependency inversion) that must
be implemented by interface components.
l Do not mix different types of components in the same logical layer. Start by
identifying different areas of concern, and then group components associated
with each area of concern into logical layers. For example, the UI layer should
not contain business processing components, but instead should contain com-
ponents used to handle user input and process user requests.
l Keep the data format consistent within a layer or component. Mixing data for-
mats will make the application more difficult to implement, extend, and maintain.
Every time you need to convert data from one format to another, you are required
to implement translation code to perform the operation and incur a processing
overhead.
Components, Modules, and Functions
l A component or an object should not rely on internal details of other components
or objects. Each component or object should call a method of another object or
component, and that method should have information about how to process the
request and, if appropriate, how to route it to appropriate subcomponents or other
components. This helps to create an application that is more maintainable and
adaptable.
.NET Application Architecture Guide, 2nd Edition
14
l Do not overload the functionality of a component. For example, a UI processing
component should not contain data access code or attempt to provide additional
functionality. Overloaded components often have many functions and properties
providing business functionality mixed with crosscutting functionality such as
logging and exception handling. The result is a design that is very error prone
and difficult to maintain. Applying the single responsibility and separation of
concerns principles will help you to avoid this.
l Understand how components will communicate with each other. This requires
an understanding of the deployment scenarios your application must support.
You must determine if all components will run within the same process, or if
communication across physical or process boundaries must be supported—
perhaps by implementing message-based interfaces.
l Keep crosscutting code abstracted from the application business logic as far as
possible. Crosscutting code refers to code related to security, communications, or
operational management such as logging and instrumentation. Mixing the code that
implements these functions with the business logic can lead to a design that is dif-
ficult to extend and maintain. Changes to the crosscutting code require touching all
of the business logic code that is mixed with the crosscutting code. Consider using
frameworks and techniques (such as aspect oriented programming) that can help to
manage crosscutting concerns.
l Define a clear contract for components. Components, modules, and functions
should define a contract or interface specification that describes their usage and
behavior clearly. The contract should describe how other components can access
the internal functionality of the component, module, or function; and the behavior
of that functionality in terms of pre-conditions, post-conditions, side effects, excep-
tions, performance characteristics, and other factors.
Key Design Considerations
This guide describes the major decisions that you must make, and which help to ensure
that you consider all of the important factors as you begin and then iteratively develop
your architecture design. The major decisions, briefly described in the following
sections, are:
l Determine the Application Type
l Determine the Deployment Strategy
l Determine the Appropriate Technologies
l Determine the Quality Attributes
l Determine the Crosscutting Concerns
For a more detailed description of the design process, see Chapter 4, “A Technique
for Architecture and Design.”
Chapter 2: Key Principles of Software Architecture 15
Determine the Application Type
Choosing the appropriate application type is the key part of the process of designing
an application. Your choice is governed by your specific requirements and infrastruc-
ture limitations. Many applications must support multiple types of client, and may
make use of more than one of the basic archetypes. This guide covers the following
basic application types:
l Applications designed for mobile devices.
l Rich client applications designed to run primarily on a client PC.
l Rich Internet applications designed to be deployed from the Internet, which
support rich UI and media scenarios.
l Service applications designed to support communication between loosely
coupled components.
l Web applications designed to run primarily on the server in fully connected
scenarios.
In addition, it provides information and guidelines for some more specialist application
types. These include the following:
l Hosted and cloud-based applications and services.
l Office Business Applications (OBAs) that integrate Microsoft Office and Microsoft
server technologies.
l SharePoint Line of Business (LOB) applications that provide portal style access to
business information and functions.
For more information about application archetypes, see Chapter 20, “Choosing an
Application Type.”
Determine the Deployment Strategy
Your application may be deployed in a variety of environments, each with its own
specific set of constraints such as physical separation of components across different
servers, a limitation on networking protocols, firewall and router configurations, and
more. Several common deployment patterns exist, which describe the benefits and con-
siderations for a range of distributed and non-distributed scenarios. You must balance
the requirements of the application with the appropriate patterns that the hardware can
support, and the constraints that the environment exerts on your deployment options.
These factors will influence your architecture design.
For more information about deployment issues, see Chapter 19, “Physical Tiers and
Deployment.”
.NET Application Architecture Guide, 2nd Edition
16
Determine the Appropriate Technologies
When choosing technologies for your application, the key factors to consider are the
type of application you are developing and your preferred options for application
deployment topology and architectural styles. Your choice of technologies will also be
governed by organization policies, infrastructure limitations, resource skills, and so on.
You must compare the capabilities of the technologies you choose against your applica-
tion requirements, taking into account all of these factors before making decisions.
For more information about technologies available on the Microsoft platform, see
Appendix A, “The Microsoft Application Platform.”
Determine the Quality Attributes
Quality attributes—such as security, performance, and usability—can be used to focus
your thinking on the critical problems that your design should solve. Depending on
your requirements, you might need to consider every quality attribute covered in this
guide, or you might only need to consider a subset. For example, every application
design must consider security and performance, but not every design needs to con-
sider interoperability or scalability. Understand your requirements and deployment
scenarios first so that you know which quality attributes are important for your
design. Keep in mind that quality attributes may conflict; for example, security often
requires a tradeoff against performance or usability.
When designing to accommodate quality attributes, consider the following guidelines:
l Quality attributes are system properties that are separate from the functionality of
the system.
l From a technical perspective, implementing quality attributes can differentiate a
good system from a bad one.
l There are two types of quality attributes: those that are measured at run time, and
those that can only be estimated through inspection.
l Analyze the tradeoffs between quality attributes.
Questions you should ask when considering quality attributes include:
l What are the key quality attributes required for your application? Identify them as
part of the design process.
l What are the key requirements for addressing these attributes? Are they actually
quantifiable?
l What are the acceptance criteria that will indicate that you have met the require-
ments?
For more information about quality attributes, see Chapter 16, “Quality Attributes.”
Chapter 2: Key Principles of Software Architecture 17
Determine the Crosscutting Concerns
Crosscutting concerns represent key areas of your design that are not related to a
specific layer in your application. For example, you should consider implementing
centralized or common solutions for the following:
l A logging mechanism that allows each layer to log to a common store, or log to
separate stores in such a way that the results can be correlated afterwards.
l A mechanism for authentication and authorization that passes identities across
multiple layers to permit granting access to resources.
l An exception management framework that will work within each layer, and
across the layers as exceptions are propagated to the system boundaries.
l A communication approach that you can use to communicate between the
layers.
l A common caching infrastructure that allows you to cache data in the presenta-
tion layer, the business layer, and the data access layer.
The following list describes some of the key crosscutting concerns that you must
consider when architecting your applications:
l Instrumentation and logging. Instrument all of the business-critical and system-
critical events, and log sufficient details to recreate events in your system without
including sensitive information.
l Authentication. Determine how to authenticate your users and pass authenticated
identities across the layers.
l Authorization. Ensure proper authorization with appropriate granularity within
each layer, and across trust boundaries.
l Exception management. Catch exceptions at functional, logical, and physical
boundaries; and avoid revealing sensitive information to end users.
l Communication. Choose appropriate protocols, minimize calls across the network,
and protect sensitive data passing over the network.
l Caching. Identify what should be cached, and where to cache, to improve your
application’s performance and responsiveness. Ensure that you consider Web
farm and application farm issues when designing caching.
For more information about crosscutting concerns, see Chapter 17, “Crosscutting
Concerns.”
3
Architectural Patterns and Styles
Overview
This chapter describes and discusses high level patterns and principles commonly used
for applications today. These are often referred to as the architectural styles, and include
patterns such as client/server, layered architecture, component-based architecture,
message bus architecture, and service-oriented architecture (SOA). For each style, you
will find an overview, key principles, major benefits, and information that will help
you choose the appropriate architectural styles for your application. It is important to
understand that the styles describe different aspects of applications. For example, some
architectural styles describe deployment patterns, some describe structure and design
issues, and others describe communication factors. Therefore, a typical application will
usually use a combination of more than one of the styles described in this chapter.
What Is an Architectural Style?
An architectural style, sometimes called an architectural pattern, is a set of principles—
a coarse grained pattern that provides an abstract framework for a family of systems.
An architectural style improves partitioning and promotes design reuse by providing
solutions to frequently recurring problems. You can think of architecture styles and
patterns as sets of principles that shape an application. Garlan and Shaw define an
architectural style as:
“…a family of systems in terms of a pattern of structural organization. More
specifically, an architectural style determines the vocabulary of components
and connectors that can be used in instances of that style, together with a set
of constraints on how they can be combined. These can include topological
constraints on architectural descriptions (e.g., no cycles). Other constraints—say,
having to do with execution semantics—might also be part of the style definition.”
[David Garlan and Mary Shaw, January 1994, CMU-CS-94-166, see “An Introduction
to Software Architecture” at http://www.cs.cmu.edu/afs/cs/project/able/ftp/
intro_softarch/intro_softarch.pdf]
Contents
3 19
Architectural Patterns and Styles 19
Overview .....................................................................19
What Is an Architectural Style? ...................................................19
Summary of Key Architectural Styles ..............................................20
Combining Architectural Styles .................................................21
Client/Server Architectural Style ..................................................21
Component-Based Architectural Style .............................................23
Domain Driven Design Architectural Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Layered Architectural Style ......................................................26
Message Bus Architectural Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
N-Tier / 3-Tier Architectural Style .................................................30
Object-Oriented Architectural Style ................................................32
Service-Oriented Architectural Style ...............................................33
Additional Resources ...........................................................35
.NET Application Architecture Guide, 2nd Edition
20
An understanding of architectural styles provides several benefits. The most impor-
tant benefit is that they provide a common language. They also provide opportuni-
ties for conversations that are technology agnostic. This facilitates a higher level of
conversation that is inclusive of patterns and principles, without getting into specif-
ics. For example, by using architecture styles, you can talk about client/server versus
n-tier. Architectural styles can be organized by their key focus area. The following
table lists the major areas of focus and the corresponding architectural styles.
Category Architecture styles
Communication Service-Oriented Architecture (SOA), Message Bus
Deployment Client/Server, N-Tier, 3-Tier
Domain Domain Driven Design
Structure Component-Based, Object-Oriented, Layered Architecture
Summary of Key Architectural Styles
The following table lists the common architectural styles described in this chapter. It
also contains a brief description of each style. Later sections of this chapter contain
more details of each style, as well as guidance to help you choose the appropriate
ones for your application.
Architecture style Description
Client/Server Segregates the system into two applications, where the client makes requests
to the server. In many cases, the server is a database with application logic
represented as stored procedures.
Component-Based
Architecture
Decomposes application design into reusable functional or logical compo-
nents that expose well-dened communication interfaces.
Domain Driven
Design
An object-oriented architectural style focused on modeling a business domain
and dening business objects based on entities within the business domain.
Layered Architecture Partitions the concerns of the application into stacked groups (layers).
Message Bus An architecture style that prescribes use of a software system that can
receive and send messages using one or more communication channels, so
that applications can interact without needing to know specic details about
each other.
N-Tier / 3-Tier Segregates functionality into separate segments in much the same way as
the layered style, but with each segment being a tier located on a physically
separate computer.
Object-Oriented A design paradigm based on division of responsibilities for an application or
system into individual reusable and self-sufcient objects, each containing
the data and the behavior relevant to the object.
Service-Oriented
Architecture (SOA)
Refers to applications that expose and consume functionality as a service
using contracts and messages.
Chapter 3: Architectural Patterns and Styles 21
Combining Architectural Styles
The architecture of a software system is almost never limited to a single architectural
style, but is often a combination of architectural styles that make up the complete
system. For example, you might have a SOA design composed of services developed
using a layered architecture approach and an object-oriented architecture style.
A combination of architecture styles is also useful if you are building a public facing
Web application, where you can achieve effective separation of concerns by using the
layered architecture style. This will separate your presentation logic from your busi-
ness logic and your data access logic. Your organization’s security requirements might
force you to deploy the application using either the 3-tier deployment approach,
or a deployment of more than three tiers. The presentation tier may be deployed to
the perimeter network, which sits between an organization’s internal network and
an external network. On your presentation tier, you may decide to use a separated
presentation pattern (a type of layered design style), such as Model-View-Controller
(MVC), for your interaction model. You might also choose a SOA architecture style,
and implement message-based communication, between your Web server and applica-
tion server.
If you are building a desktop application, you may have a client that sends requests to
a program on the server. In this case, you might deploy the client and server using the
client/server architecture style, and use the component-based architecture style to de-
compose the design further into independent components that expose the appropriate
communication interfaces. Using the object-oriented design approach for these compo-
nents will improve reuse, testability, and flexibility.
Many factors will influence the architectural styles you choose. These factors include
the capacity of your organization for design and implementation; the capabilities
and experience of your developers; and your infrastructure and organizational con-
straints. The following sections will help you to determine the appropriate styles
for your applications.
Client/Server Architectural Style
The client/server architectural style describes distributed systems that involve a
separate client and server system, and a connecting network. The simplest form of
client/server system involves a server application that is accessed directly by mul-
tiple clients, referred to as a 2-Tier architectural style.
.NET Application Architecture Guide, 2nd Edition
22
Historically, client/server architecture indicated a graphical desktop UI application
that communicated with a database server containing much of the business logic in the
form of stored procedures, or with a dedicated file server. More generally, however, the
client/server architectural style describes the relationship between a client and one or
more servers, where the client initiates one or more requests (perhaps using a graphical
UI), waits for replies, and processes the replies on receipt. The server typically autho-
rizes the user and then carries out the processing required to generate the result. The
server may send responses using a range of protocols and data formats to communi-
cate information to the client.
Today, some examples of the client/server architectural style include Web browser–
based programs running on the Internet or an intranet; Microsoft Windows® operating
system–based applications that access networked data services; applications that access
remote data stores (such as e-mail readers, FTP clients, and database query tools); and
tools and utilities that manipulate remote systems (such as system management tools
and network monitoring tools).
Other variations on the client/server style include:
l Client-Queue-Client systems. This approach allows clients to communicate with
other clients through a server-based queue. Clients can read data from and send
data to a server that acts simply as a queue to store the data. This allows clients to
distribute and synchronize files and information. This is sometimes known as a
passive queue architecture.
l Peer-to-Peer (P2P) applications. Developed from the Client-Queue-Client style,
the P2P style allows the client and server to swap their roles in order to distribute
and synchronize files and information across multiple clients. It extends the client/
server style through multiple responses to requests, shared d