SHORT SUMMARY NOTES
Embedded Files
Topics 119–127: Software Architecture Fundamentals
• Topic 119: Definition. Software architecture acts as a bridge between abstract business goals and the concrete resulting system1. It encompasses software elements, the relations among them, and their properties2.
• Topic 120: Categories. Structures are divided into three categories: Static (implementation units), Dynamic (runtime behavior/components), and Deployment (allocation to hardware)3.
• Topic 121: Module Structures. These are static structures focusing on how functionality is assigned to implementation teams. Examples include Class Diagrams and Layered Structures45.
• Topic 122: C&C and Allocation. Component-and-Connector (C&C) structures focus on runtime interaction (services, synchronization). Allocation structures map software to hardware/environments67.
• Topic 123: Quality Attributes. A structure is architectural if it supports reasoning about system properties (quality attributes) like availability or responsiveness78.
• Topic 124: Abstraction. Architecture abstracts the system, suppressing private details and internal implementation to manage complexity9.
• Topic 125: Documentation. Every system has an architecture, but it may not be known/documented. Documentation is essential for reasoning about the system independent of its existence10.
• Topic 126: Scope.
◦ System Architecture: Includes hardware, software, and people11.
◦ Enterprise Architecture: Aligns software with business processes and organizational goals12.
• Topic 127: Views. A view is a representation of a structure seen by a specific stakeholder. To communicate an architecture, you must specify which view/structure you are discussing13.
Topics 128–138: Views, Structures, and Recommendations
• Topic 128: 4+1 View Model. Developed by Philippe Kruchten to address different stakeholder concerns14.
◦ Logical: End-user functional requirements.
◦ Process: Integrators/Performance (concurrency).
◦ Development: Programmers (software management).
◦ Physical: System Engineers (hardware mapping).
◦ +1 Scenarios: Validates the design15....
• Topic 129: Module Structure Analysis. Helps answer questions about functional responsibility and modifiability (impact of changes)18.
• Topic 130: C&C Structure Analysis. Helps reason about runtime properties like performance, security, and availability19.
• Topic 131: Allocation Structure Analysis. Used for project management, configuration control, and performance analysis regarding hardware20.
• Topic 132: Structures & Quality. Different structures support different attributes. For example, the "uses" structure relates to extendibility; deployment relates to performance/availability20.
• Topic 133: Relating Structures. Structures are not independent; elements in one view (e.g., module) map to elements in another (e.g., component) often in a many-to-many relationship21.
• Topic 134: Rigor. Only design/document structures that provide a positive ROI for the specific system size and complexity22.
• Topic 135: Patterns Overview. Patterns are packaged strategies for recurring problems. Examples: Layered (Module), Shared Data (C&C), Multi-tier (Allocation)2324.
• Topic 136: Evaluation. No architecture is inherently "good"; it is evaluated based on its fitness for specific goals25.
• Topic 137: Process Recommendations. Use a single architect/technical leader, document using views, evaluate early, and implement incrementally (skeletal system)2627.
• Topic 138: Product Recommendations. Use information hiding, separate data producers from consumers, and avoid dependency on specific tool versions2829.
Topics 139–149: The Architecture Meta-Frame
• Topic 139: Architectural Drivers. The inputs for design: design objectives, functional requirements, quality attribute scenarios, and constraints30.
• Topic 140: Meta-Frame. A collection of hotspots (e.g., caching, validation) used to analyze architecture31.
• Topic 141-144: Quality Attributes (QA). Measurable properties indicating how well the system satisfies stakeholder needs. Examples: Availability (uptime), Reliability (probability of non-failure), Scalability (handling load), Security (protection)3233.
• Topic 145: Constraints. Design decisions with zero degrees of freedom (e.g., budget, specific technology, legal)33.
• Topic 146-148: Application Types. Categories of technology stacks. Examples: Mobile, Rich Client (disconnected scenarios), Rich Internet (browser sandbox), Service (loose coupling), Web App (server-side processing)34....
• Topic 149: Architectural Styles. Principles shaping the design (e.g., Client-Server, SOA, N-Tier). Choice depends on organization capacity and infrastructure37.
Topics 150–164: Engineering Decisions & Process
• Topic 150-151: Cross-Cutting Concerns. Design areas affecting multiple layers (e.g., Authentication, Logging, Caching)3839.
• Topic 152: Auth & Auth. Authentication identifies users; Authorization determines access rights40.
• Topic 153: Caching. Improves performance and reduces round trips. Requires decisions on expiration and loading strategies41.
• Topic 154: Communication. Protocols and strategies for moving data across layers/tiers42.
• Topic 155: Concurrency. Handling data conflicts and transactions (atomic operations)43.
• Topic 156: Data Access. Managing connections, exceptions, and paging records44.
• Topic 157: User Experience. Usability, responsiveness, and user empowerment45.
• Topic 158: Agility. Architectures evolve. Identify "foundational" parts that are risky to change and fix them early46.
• Topic 159: Principles. Build to change, model to analyze risk, and use models for communication47.
• Topic 160: Incremental Approach. Don't design everything at once. Focus on big decisions first, then details48.
• Topic 161: Baseline vs. Candidate. Baseline: How the system looks today. Candidate: Proposed architecture to test against requirements49.
• Topic 162: Architectural Spike. End-to-end test of a small segment to reduce risk50.
• Topic 163: Architecturally Significant Use Cases. Critical use cases used to evaluate the success of candidate architectures51.
• Topic 164: Reference Architecture. A canonical view (template) showing typical layers and cross-cutting concerns52.
Topics 165–184: Architectural Patterns
• Topic 165: Definition. A solution to a recurring problem in a specific context53.
• Topic 166: Vs. Design Patterns. Architecture patterns are broader/coarse-grained (system level); design patterns are fine-grained (implementation level)54.
• Topic 168-172: Layered Pattern.
◦ Concept: Code divided into horizontal layers (Presentation, Business, Data).
◦ Open vs. Closed: Closed layers must go through the layer immediately below (isolation); Open layers can bypass (performance but higher coupling)55....
◦ Tiers vs. Layers: Layers are logical; Tiers are physical58.
◦ Pros: Separation of Concerns, testability, ease of development.
◦ Cons: Performance overhead, "leaky" logic, requires code for passthrough5960.
• Topic 173: Client-Server. Two-tier. Thick client (logic on client) vs. Thin client (logic on server)61.
• Topic 174: N-Tier. Typically 3-tier: Presentation (UI), Business (Logic/Workflows), Data (Storage)6263.
• Topic 176-177: Broker Pattern. Decouples clients from servers using an intermediary. Supports dynamic binding but adds complexity and latency6465.
• Topic 178: MVC. Model-View-Controller. Separates UI responsibilities. Good for Web Apps66.
• Topic 179-180: Pipe-and-Filter. Successive transformation of data streams. Filters are independent; Pipes buffer data. Good for reuse/parallelism; bad for interactive systems6768.
• Topic 182-183: Shared-Data. Components interact via a persistent data store. Decouples producers/consumers but can create a performance bottleneck (single point of failure)6970.
• Topic 184: Multi-tier (Allocation). Mapping software tiers to physical computing environments71.
Topics 185–186: Monolithic Architecture
• Topic 185: Definition. Application designed as a single, self-contained unit. Components are tightly coupled72.
• Topic 186: Pros/Cons.
◦ Pros: Simpler to deploy (small apps), better performance, easier to scale (horizontally).
◦ Cons: Inhibits agility (redeployment of whole app required for small changes), technology lock-in, low maintainability73.
Topics 187–212: Web Application Architecture
• Topic 187: Overview. Core is server-side logic, typically 3-layered (Presentation, Business, Data)74.
• Topic 188-190: Design. Partition logically (Maintainability), reduce round trips/use caching (Performance), and authenticate across boundaries (Security)75....
• Topic 192: Authentication. Identify trust boundaries. Don't store plain-text passwords78.
• Topic 193: Authorization. Granularity matters. Use the trusted subsystem model for downstream resources79.
• Topic 194: Caching. Most important performance factor. Avoid caching volatile or sensitive data. Use output caching for static pages8081.
• Topic 195: Exceptions. Do not use exceptions for logic flow. Catch at boundaries. Do not reveal sensitive info to users82.
• Topic 202: Session Management. Secure communication channels. Use timeouts. Choose between in-process (fast, single server) or out-of-process (web farm)83.
• Topic 203: Validation. Validate at trust boundaries. Client-side for UX; Server-side for security84.
• Topic 205: Business Layer. Should be stateless. Implements workflows and business entities85.
• Topic 212: Load Balancing. Distributes requests. Avoid Server Affinity (when a client is tied to one server) to ensure scalability8687.
Topics 213–217: Cloud Computing
• Topic 213-214: Definition. On-demand, self-service, resource pooling, rapid elasticity, and measured service8889.
• Topic 215: Service Models.
◦ SaaS: Consumer uses apps (Email).
◦ PaaS: Consumer uses platform/tools to build apps.
◦ IaaS: Consumer provisions raw processing/storage9091.
• Topic 216: Multi-tenancy. Single app instance serves multiple client organizations (tenants). updates applied once for everyone92.
• Topic 217: Architecting. Focus on Security (multi-tenancy risks), Performance (elasticity), and Availability (plan for failure/stateless services)9394.
Topics 218–221: Service-Oriented Architecture (SOA)
• Topic 218: Definition. Loosely coupled services working together. Decomposes logic into reusable units95.
• Topic 219: Difference. Distinct from general distributed computing by its focus on Separation of Concerns (SoC) and reusable logic96.
• Topic 220: Benefits. Alignment with business, vendor diversity, federation97.
• Topic 221: Challenges. Increased scope and complexity; difficulty in troubleshooting distributed transactions98.
Topics 222–226: Microservice Architecture (MSA)
• Topic 222: Definition. Application built as small, autonomous, independently deployable services99.
• Topic 223: Components. Uses API Gateway as an entry point. Each service has independent data storage100.
• Topic 224: Polyglot.
◦ Polyglot Programming: Using different languages for different services.
◦ Polyglot Persistence: Using different databases (SQL, NoSQL) based on service needs101.
• Topic 225: Stateless vs Stateful. Stateless services (preferred for cloud) do not store session data on the server, improving scalability102.
• Topic 226: Challenges. Complexity of distributed systems, managing many services, and handling distributed transactions across multiple databases103.
Topic 227: General Wisdom
• Topic 227: Architecture is about balancing tradeoffs. "Simplicity before generality." Architects must communicate effectively and be hands-on
Topics 119–127: Software Architecture Fundamentals
• Topic 119: Definition. Software architecture acts as a bridge between abstract business goals and the concrete resulting system1. It encompasses software elements, the relations among them, and their properties2.
• Topic 120: Categories. Structures are divided into three categories: Static (implementation units), Dynamic (runtime behavior/components), and Deployment (allocation to hardware)3.
• Topic 121: Module Structures. These are static structures focusing on how functionality is assigned to implementation teams. Examples include Class Diagrams and Layered Structures45.
• Topic 122: C&C and Allocation. Component-and-Connector (C&C) structures focus on runtime interaction (services, synchronization). Allocation structures map software to hardware/environments67.
• Topic 123: Quality Attributes. A structure is architectural if it supports reasoning about system properties (quality attributes) like availability or responsiveness78.
• Topic 124: Abstraction. Architecture abstracts the system, suppressing private details and internal implementation to manage complexity9.
• Topic 125: Documentation. Every system has an architecture, but it may not be known/documented. Documentation is essential for reasoning about the system independent of its existence10.
• Topic 126: Scope.
◦ System Architecture: Includes hardware, software, and people11.
◦ Enterprise Architecture: Aligns software with business processes and organizational goals12.
• Topic 127: Views. A view is a representation of a structure seen by a specific stakeholder. To communicate an architecture, you must specify which view/structure you are discussing13.
Topics 128–138: Views, Structures, and Recommendations
• Topic 128: 4+1 View Model. Developed by Philippe Kruchten to address different stakeholder concerns14.
◦ Logical: End-user functional requirements.
◦ Process: Integrators/Performance (concurrency).
◦ Development: Programmers (software management).
◦ Physical: System Engineers (hardware mapping).
◦ +1 Scenarios: Validates the design15....
• Topic 129: Module Structure Analysis. Helps answer questions about functional responsibility and modifiability (impact of changes)18.
• Topic 130: C&C Structure Analysis. Helps reason about runtime properties like performance, security, and availability19.
• Topic 131: Allocation Structure Analysis. Used for project management, configuration control, and performance analysis regarding hardware20.
• Topic 132: Structures & Quality. Different structures support different attributes. For example, the "uses" structure relates to extendibility; deployment relates to performance/availability20.
• Topic 133: Relating Structures. Structures are not independent; elements in one view (e.g., module) map to elements in another (e.g., component) often in a many-to-many relationship21.
• Topic 134: Rigor. Only design/document structures that provide a positive ROI for the specific system size and complexity22.
• Topic 135: Patterns Overview. Patterns are packaged strategies for recurring problems. Examples: Layered (Module), Shared Data (C&C), Multi-tier (Allocation)2324.
• Topic 136: Evaluation. No architecture is inherently "good"; it is evaluated based on its fitness for specific goals25.
• Topic 137: Process Recommendations. Use a single architect/technical leader, document using views, evaluate early, and implement incrementally (skeletal system)2627.
• Topic 138: Product Recommendations. Use information hiding, separate data producers from consumers, and avoid dependency on specific tool versions2829.
Topics 139–149: The Architecture Meta-Frame
• Topic 139: Architectural Drivers. The inputs for design: design objectives, functional requirements, quality attribute scenarios, and constraints30.
• Topic 140: Meta-Frame. A collection of hotspots (e.g., caching, validation) used to analyze architecture31.
• Topic 141-144: Quality Attributes (QA). Measurable properties indicating how well the system satisfies stakeholder needs. Examples: Availability (uptime), Reliability (probability of non-failure), Scalability (handling load), Security (protection)3233.
• Topic 145: Constraints. Design decisions with zero degrees of freedom (e.g., budget, specific technology, legal)33.
• Topic 146-148: Application Types. Categories of technology stacks. Examples: Mobile, Rich Client (disconnected scenarios), Rich Internet (browser sandbox), Service (loose coupling), Web App (server-side processing)34....
• Topic 149: Architectural Styles. Principles shaping the design (e.g., Client-Server, SOA, N-Tier). Choice depends on organization capacity and infrastructure37.
Topics 150–164: Engineering Decisions & Process
• Topic 150-151: Cross-Cutting Concerns. Design areas affecting multiple layers (e.g., Authentication, Logging, Caching)3839.
• Topic 152: Auth & Auth. Authentication identifies users; Authorization determines access rights40.
• Topic 153: Caching. Improves performance and reduces round trips. Requires decisions on expiration and loading strategies41.
• Topic 154: Communication. Protocols and strategies for moving data across layers/tiers42.
• Topic 155: Concurrency. Handling data conflicts and transactions (atomic operations)43.
• Topic 156: Data Access. Managing connections, exceptions, and paging records44.
• Topic 157: User Experience. Usability, responsiveness, and user empowerment45.
• Topic 158: Agility. Architectures evolve. Identify "foundational" parts that are risky to change and fix them early46.
• Topic 159: Principles. Build to change, model to analyze risk, and use models for communication47.
• Topic 160: Incremental Approach. Don't design everything at once. Focus on big decisions first, then details48.
• Topic 161: Baseline vs. Candidate. Baseline: How the system looks today. Candidate: Proposed architecture to test against requirements49.
• Topic 162: Architectural Spike. End-to-end test of a small segment to reduce risk50.
• Topic 163: Architecturally Significant Use Cases. Critical use cases used to evaluate the success of candidate architectures51.
• Topic 164: Reference Architecture. A canonical view (template) showing typical layers and cross-cutting concerns52.
Topics 165–184: Architectural Patterns
• Topic 165: Definition. A solution to a recurring problem in a specific context53.
• Topic 166: Vs. Design Patterns. Architecture patterns are broader/coarse-grained (system level); design patterns are fine-grained (implementation level)54.
• Topic 168-172: Layered Pattern.
◦ Concept: Code divided into horizontal layers (Presentation, Business, Data).
◦ Open vs. Closed: Closed layers must go through the layer immediately below (isolation); Open layers can bypass (performance but higher coupling)55....
◦ Tiers vs. Layers: Layers are logical; Tiers are physical58.
◦ Pros: Separation of Concerns, testability, ease of development.
◦ Cons: Performance overhead, "leaky" logic, requires code for passthrough5960.
• Topic 173: Client-Server. Two-tier. Thick client (logic on client) vs. Thin client (logic on server)61.
• Topic 174: N-Tier. Typically 3-tier: Presentation (UI), Business (Logic/Workflows), Data (Storage)6263.
• Topic 176-177: Broker Pattern. Decouples clients from servers using an intermediary. Supports dynamic binding but adds complexity and latency6465.
• Topic 178: MVC. Model-View-Controller. Separates UI responsibilities. Good for Web Apps66.
• Topic 179-180: Pipe-and-Filter. Successive transformation of data streams. Filters are independent; Pipes buffer data. Good for reuse/parallelism; bad for interactive systems6768.
• Topic 182-183: Shared-Data. Components interact via a persistent data store. Decouples producers/consumers but can create a performance bottleneck (single point of failure)6970.
• Topic 184: Multi-tier (Allocation). Mapping software tiers to physical computing environments71.
Topics 185–186: Monolithic Architecture
• Topic 185: Definition. Application designed as a single, self-contained unit. Components are tightly coupled72.
• Topic 186: Pros/Cons.
◦ Pros: Simpler to deploy (small apps), better performance, easier to scale (horizontally).
◦ Cons: Inhibits agility (redeployment of whole app required for small changes), technology lock-in, low maintainability73.
Topics 187–212: Web Application Architecture
• Topic 187: Overview. Core is server-side logic, typically 3-layered (Presentation, Business, Data)74.
• Topic 188-190: Design. Partition logically (Maintainability), reduce round trips/use caching (Performance), and authenticate across boundaries (Security)75....
• Topic 192: Authentication. Identify trust boundaries. Don't store plain-text passwords78.
• Topic 193: Authorization. Granularity matters. Use the trusted subsystem model for downstream resources79.
• Topic 194: Caching. Most important performance factor. Avoid caching volatile or sensitive data. Use output caching for static pages8081.
• Topic 195: Exceptions. Do not use exceptions for logic flow. Catch at boundaries. Do not reveal sensitive info to users82.
• Topic 202: Session Management. Secure communication channels. Use timeouts. Choose between in-process (fast, single server) or out-of-process (web farm)83.
• Topic 203: Validation. Validate at trust boundaries. Client-side for UX; Server-side for security84.
• Topic 205: Business Layer. Should be stateless. Implements workflows and business entities85.
• Topic 212: Load Balancing. Distributes requests. Avoid Server Affinity (when a client is tied to one server) to ensure scalability8687.
Topics 213–217: Cloud Computing
• Topic 213-214: Definition. On-demand, self-service, resource pooling, rapid elasticity, and measured service8889.
• Topic 215: Service Models.
◦ SaaS: Consumer uses apps (Email).
◦ PaaS: Consumer uses platform/tools to build apps.
◦ IaaS: Consumer provisions raw processing/storage9091.
• Topic 216: Multi-tenancy. Single app instance serves multiple client organizations (tenants). updates applied once for everyone92.
• Topic 217: Architecting. Focus on Security (multi-tenancy risks), Performance (elasticity), and Availability (plan for failure/stateless services)9394.
Topics 218–221: Service-Oriented Architecture (SOA)
• Topic 218: Definition. Loosely coupled services working together. Decomposes logic into reusable units95.
• Topic 219: Difference. Distinct from general distributed computing by its focus on Separation of Concerns (SoC) and reusable logic96.
• Topic 220: Benefits. Alignment with business, vendor diversity, federation97.
• Topic 221: Challenges. Increased scope and complexity; difficulty in troubleshooting distributed transactions98.
Topics 222–226: Microservice Architecture (MSA)
• Topic 222: Definition. Application built as small, autonomous, independently deployable services99.
• Topic 223: Components. Uses API Gateway as an entry point. Each service has independent data storage100.
• Topic 224: Polyglot.
◦ Polyglot Programming: Using different languages for different services.
◦ Polyglot Persistence: Using different databases (SQL, NoSQL) based on service needs101.
• Topic 225: Stateless vs Stateful. Stateless services (preferred for cloud) do not store session data on the server, improving scalability102.
• Topic 226: Challenges. Complexity of distributed systems, managing many services, and handling distributed transactions across multiple databases103.
Topic 227: General Wisdom
• Topic 227: Architecture is about balancing tradeoffs. "Simplicity before generality." Architects must communicate effectively and be hands-on
Page updated
Google Sites
Report abuse