Chapter 8 Flashcards — Component-Based Thinking
flashcards fsa components component-design logical-architecture
What is a component in software architecture?
?
A component is the fundamental modular building block of an architecture — a named, cohesive grouping of related code that encapsulates a well-defined set of business responsibilities and exposes behavior through an interface. Components sit above the class/module level in the abstraction hierarchy.
What is the difference between logical architecture and physical architecture?
?
Logical architecture describes conceptual components and their relationships, independent of deployment technology — it answers “what are the building blocks and how do they relate?” Physical architecture describes how logical components map to actual deployment units (containers, services, databases) — it answers “how is this system deployed?” Logical architecture should always precede physical.
Why should architects define logical architecture before physical architecture?
?
Jumping straight to physical decisions (e.g., “we’ll use microservices”) before understanding logical components leads to premature commitment — deployment-driven decomposition rather than responsibility-driven decomposition. Structural mistakes made at the physical level are expensive to reverse and hard to communicate to stakeholders.
What is the entity trap antipattern?
?
The entity trap is designing components that mirror database entities (CustomerComponent, OrderComponent, ProductComponent). This produces anemic, CRUD-only components with no business logic cohesion. Components should represent business capabilities and workflows, not data records.
What are the 5 steps in the logical architecture creation process from Chapter 8?
?
- Identify core components from requirements (candidate list). 2. Assign user stories to components (stress-test the decomposition). 3. Analyze roles and responsibilities (check cohesion, split or merge). 4. Analyze architectural characteristics per component (identify quantum boundaries). 5. Restructure components based on analysis. Steps 2–5 are iterative.
What does Step 2 (assigning user stories to components) reveal about a component design?
?
User story mapping reveals gaps and overlaps: stories that can’t be assigned to any component reveal missing components; one component absorbing most stories suggests it needs to be split; stories that touch every component suggest the decomposition is too granular. It stress-tests the initial candidate list.
What is static coupling between components?
?
Static coupling is a compile-time dependency — one component imports, references, or calls another component’s code directly. It creates a hard dependency that must be managed at build and deployment time. High static coupling across component boundaries makes independent evolution difficult; it is acceptable within a component.
What is temporal coupling between components?
?
Temporal coupling (runtime availability coupling) exists when one component can only function if another is available at the same moment — the classic form is a synchronous API call. If A calls B synchronously, A is temporally coupled to B: B’s downtime causes A’s failures. More dangerous than static coupling because it affects production resilience.
How does temporal coupling differ from static coupling in terms of risk?
?
Static coupling is a build-time risk — it complicates versioning and deployment coordination. Temporal coupling is a runtime risk — it reduces system availability and resilience in production. A system can have low static coupling but high temporal coupling (microservices calling each other synchronously) and still have poor resilience.
What is the Law of Demeter, and what does it mean for component design?
?
The Law of Demeter (Principle of Least Knowledge) states a component should only interact with its immediate collaborators, not reach through them to access another component’s internals. In architecture: Component A should talk to B through B’s interface; A should not know B’s internal structure just to reach C. Violations create hidden, brittle coupling.
What is the architectural consequence of violating the Law of Demeter?
?
Violating the Law of Demeter creates hidden coupling — Component A becomes dependent on the internal structure of B and the existence of C, even though this is not expressed in A’s declared interface. Refactoring becomes brittle: changing C’s interface or B’s internal structure silently breaks A. In distributed systems this manifests as deep synchronous chains.
In the Going Going Gone case study, what are the six core components identified?
?
- Bidder — bidder profile and authentication. 2. Auctioneer — auction control and lot progression. 3. Auction — auction lifecycle (open/active/closed). 4. Bid Stream — pushes live auction state to bidders. 5. Bid Capture — receives and validates incoming bids. 6. Bid Tracker — tracks current highest bid, enforces bid increment rules.
Why are Bid Stream and Bid Capture treated as separate components in Going Going Gone?
?
Bid Stream is outbound (pushes auction state to watching bidders) while Bid Capture is inbound (receives bids from bidders). They have different communication directions and different operational profiles: Bid Stream needs very high fan-out scalability; Bid Capture needs very low latency strong consistency for bid validation. Different responsibilities and profiles warrant separation.
Why is Bid Tracker separated from the Auction component in Going Going Gone?
?
Auction manages lifecycle (open/advance/close lots), while Bid Tracker manages real-time bid state (current high bid, bid increments, winner notification). These are distinct responsibilities. Additionally, Bid Tracker requires very low latency — a different operational profile from the Auction lifecycle management, which justifies separation.
What are the four quanta identified in a microservices deployment of Going Going Gone?
?
- Bidder — moderate availability, high read scalability. 2. Auction + Auctioneer + Bid Tracker — high availability, strong consistency, low latency (synchronous internal calls keep them in one quantum). 3. Bid Stream — very high scalability, very low latency, eventual consistency. 4. Bid Capture — very high scalability, very low latency, strong consistency.
What is a “God Component” antipattern?
?
A God Component absorbs 50%+ of the system’s responsibilities, often named “Service” or “Manager.” It reveals insufficient decomposition effort. Detection: in step 2 of the 5-step process, one component receives most user stories. Fix: identify distinct business capabilities within it and split along responsibility boundaries.
What is the “chatty components” antipattern?
?
Chatty components make many fine-grained synchronous calls between each other, creating high temporal coupling. This often signals either that two components should be merged (they’re really one business capability) or that the interface should be redesigned around coarser-grained operations that return more data per call.
What heuristic suggests two components should be merged?
?
If two components always change together — every feature that touches one requires a change in the other — it signals they represent a single cohesive business capability that has been over-split. Merge them. Similarly, if one component is so thin it merely passes data through to another, it should be merged with the component it serves.
What heuristic suggests a component should be split?
?
A component should be split when it has multiple unrelated responsibilities (low internal cohesion), when it receives far too many user stories relative to other components, or when subsets of its functions have significantly different operational characteristic profiles (suggesting they need different quantum boundaries).
What is the difference between top-down and bottom-up component identification?
?
Top-down starts with business capabilities and decomposes into components — preferred for greenfield systems. Bottom-up examines existing code and surfaces implicit cohesion clusters — used for brownfield analysis of existing systems. Top-down aligns better with business intent; bottom-up reveals what the code actually does.
How do architectural characteristics analysis (Step 4) inform component restructuring (Step 5)?
?
Step 4 reveals components with divergent operational profiles — e.g., one sub-responsibility needs very low latency while another needs strong consistency. These divergent profiles suggest splitting the component so each piece can be treated as a separate quantum. Components with identical profiles that collaborate closely may instead be candidates for merging.
What is capability-oriented component design and why is it preferred over entity-oriented design?
?
Capability-oriented design creates components around business capabilities and workflows (e.g., OrderFulfillment, CustomerOnboarding). Entity-oriented design creates components around data records (OrderComponent, CustomerComponent). Capability-oriented design produces higher cohesion, maps naturally to business language, supports team ownership aligned with domain boundaries, and avoids the entity trap.
In the 5-step process, what is the purpose of the “analyze roles and responsibilities” step (Step 3)?
?
Step 3 reviews the user stories assigned in Step 2 and asks: does each component have a single, coherent role? Is it doing too many conceptually different things? This step surfaces components that need to be split (multiple distinct roles) or merged (too thin/anemic). The goal is high cohesion — each component has one clear reason to exist.
How should cross-component communication be designed to minimize temporal coupling?
?
Use asynchronous messaging (queues, event streams) between components that belong to different quanta. Reserve synchronous calls for components within the same quantum where the latency and availability coupling is acceptable. For synchronous calls that cross quantum boundaries, use circuit breakers and bulkhead patterns to contain failure.
What does it mean when a component is “referenced by every other component” in the architecture?
?
It typically means the component contains infrastructure concerns (logging, configuration, security utilities) rather than business logic, or it is an overly broad “utility” component. It should either be extracted into a shared library (if it is pure infrastructure with no business logic) or decomposed, as it represents a coupling hotspot that complicates independent evolution.
What is the relationship between the logical component design process and quantum identification?
?
The 5-step component design process concludes with components that each have explicit architectural characteristic profiles (Step 4). Components with similar profiles that interact synchronously form a quantum. Components with divergent profiles, or that communicate asynchronously, form separate quanta. Logical component design is the input to quantum boundary identification.
Total Cards: 26
Estimated Review Time: 22–28 minutes
Priority: HIGH
Last Updated: 2026-05-29