Microsoft Patterns and practices group released a guideline book for solution architects. The PDF version of it can be downloaded from here.
The following is my notes from the first few chapters of the book.
.Net Application Architecture
- Why: Balance between User, System & Business
-
Goal
- System Structure, Realize use cases & scenario, Meets Functional & Quality
- Landscape: User Empowerment, Market Maturity, Flexible design, Future trends
-
Principles
- Measure Risks, Priority, Assumptions, Fallback
-
Key Architecture Principles
- Build to change instead of building to last
- Model to analyze and reduce risk
- Use models and visualizations
- Identify key engineering decisions
-
Key design Principles
- Separation of concerns
- Single Responsibility principle
- Principle of Least Knowledge
- Don’t repeat yourself
- Minimize upfront design
-
Design Practices
- Keep design patterns consistent within each layer
- Do not duplicate functionality within app
- Prefer composition to inheritance
- Establish a coding style and naming convention for dev
- Maintain system quality using automated QA techniques during development.
- Consider the operation of your application.
-
Application Layers
- Separate the areas of concern.
- Be explicit about how layers communicate with each other.
- Use abstraction to implement loose coupling between layers.
- Do not mix different types of components in the same logical layer.
- Keep the data format consistent within a layer or component.
-
Components, Modules, and Functions
- A component or an object should not rely on internal details of other components or objects.
- Do not overload the functionality of a component.
- Understand how components will communicate with each other.
- Keep crosscutting code abstracted from the application business logic as far as possible.
- Define a clear contract for components.
-
Key Design Considerations
- Application Type: Mobile, Rich client, RIA, Service, Web, Cloud, OBA, SharePoint LOB
- Deployment Strategy
- Appropriate Technologies
- Quality Attributes
- Crosscutting Concerns: Logging, Authentication & Authorization, Exception, Communication, Caching, Instrumentation
-
Architectural Patterns and Styles
-
Types
- Client/Server
- Component-Based Architecture
- Domain Driven Design
- Layered Architecture
- Message Bus
- N-Tier / 3-Tier
- Object-Oriented
- Service-Oriented
- Architecture (SOA)
-
Client / Server
-
Type
- Client-Queue-Client systems.
- Peer-to-Peer (P2P) applications.
- Application servers.
- Benefit: Secure, Centralized data access, Ease of maintenance
-
-
Component based
- Benefit: Reusable, Replaceable, Not context specific, Extensible, Encapsulated, Independent
- Domain Driven
-
Layered
- Abstraction
- Encapsulation
- Clearly defined functional layers
- High cohesion
- Reusable
- Loose coupling
-
Message Bus
- Enterprise Service Bus (ESB)
- Internet Service Bus (ISB)
- N-Tier: Maintainability, Scalability, Flexibility & Availability
-
-
Technique for Architecture & Design
-
Steps
- Identify Architecture Objectives
- Key Scenarios
- Application Overview
- Key Issues
- Candidate Solutions
-
Objectives
- Identify your architecture goals at the start.
- Identify who will consume your architecture.
- Identify your constraints.
-
-
Design Steps
-
Choose Your Layering Strategy:
- Not too few or Not too many
- Physical or Logical layer (Tier / Layer)
- Performance considerations
-
Determine the Layers You Require
- Traditional: presentation, services, business, and data access
-
Decide How to Distribute Layers and Components
- Based on App type (Web, RIA, Workflow)
- Determine If You Need to Collapse Layers
-
Determine Rules for Interaction between Layers
- Top-down interaction
- Strict interaction
- Loose interaction
- Identify Cross Cutting Concerns
-
Define the Interfaces between Layers
- Abstract interface
- Common design type
- Dependency inversion
- Message-based
- Choose Your Deployment Strategy
- Choose Communication Protocols
-
Presentation Layer
-
Major divisions
- User Interface component
- Presentation Logic component
-
Consideration
- App Type, UI Technology, Relevant Pattern, Separation of concern, Consider human Interface guidelines, adhere user driven design principles.
-
Specific issues:
- Caching: Where, How and What
- Communication: Asynch, Chatty
- Composition: Avoid dependency
- Exception: Differentiate System and Business
- Navigation: Toolbar, Menu, Wizards. Avoid duplicate event handlers
- UX: Simple & clear
- User Interface: Consider MVP, Consider different size & resolutions, accessibility,
- Validation: Reject malicious input
-
Design Patterns
- Caching: Cache Dependency, Page Cache
- Composition and Layout: Composite View, Presentation Model, Template View, Transform View, Two-Step View.
- Exception: Exception Shielding
- Navigation: Application Controller, Front Controller, Page Controller and Command
- UX: Asynch callback, Chain of responsibility
Business Layer Guidelines
-
Typical parts
- Application façade
- Business Logic Components: Workflow & Entity
-
Design Considerations
- Decide if you need a separate business layer.
- Identify the responsibilities and consumers of your business layer.
- Do not mix different types of components in your business layer.
- Reduce round trips when accessing a remote business layer. (DTO)
- Avoid tight coupling between layers.
-
Design Issues
-
Authentication:
- Avoid in it if it done in same boundary in UI / Service
- Consider single sign-on, consider same user access data from diff apps.
- Make sure original caller’s access control list (ACL)
-
Authorization
- Role-based
- Avoid impersonation and delegation
- Don’t mix authorization and business logic
- Should be pervasive
- Make sure performance is not hit
-
Cache
- Consider for static data
- Avoid sensitive data
- Study implecations
-
Logging
- Apache Logging Services "log4Net" or Jarosław
- Kowalski’s "NLog,"
-
-
Design Steps
- Create a high level design for your business layer.
- Design your business components.
- Design your business entity components.
- Design your workflow components.
-
Patterns
- Business Components: Application Façade, Chain of Responsibility. Command.
- Business Entities: Domain Model, Entity Translator, Table Module
- Workflows: Data-Driven Workflow, Human Workflow, Sequential Workflow, State-Driven Workflow
Data Layer
-
Major Parts
- Data Access Components
- Service Agents
-
Design considerations
- Choose an appropriate data access technology.
- Use abstraction to implement a loosely coupled interface to the data access
- Encapsulate data access functionality within the data access layer.
- Decide how to map application entities to data source structures.
- Consider consolidating data structures.
- Decide how you will manage connections.
- Determine how you will handle data exceptions.
- Consider security risks.
- Reduce round trips.
- Consider performance and scalability objectives.
-
Issues
- Batching: Reduce round trip
- Binary Large Objects (BLOBs): Consider storage, search and retrieval
- Connections: Open as late and close as soon, transactions in single connection, connection pooling, avoid stored DSN, consider retry logics
- Data Format: XML, DataSet for CRUD and DTO serializations
- Exception Management: have a strategy, Propagation, Use retry, cleanup resource, consider logging and notification strategy
- Object Relational Mapping: Consider O/RM tools, consider Repository pattern, consider lazy loading
- Queries: User parameterized Queries, Consider Query Object pattern, For dynamic query avoid mixing generation and business logic
- Stored Procedures
- Stored Procedures vs. Dynamic SQL
- Transactions: Keep it short, have correct Isolation, use System.Transactions, consider Multiple Active Result Set (MARS)
- Validation
- XML
Guruprasad's space 