Chapter 8 — Component-Based Thinking

Why it matters

Components are the physical building blocks architects actually manipulate. This chapter is about how you arrive at a component structure.

Core ideas

• Component = the physical packaging of modules (a building block of the system), usually manifested as a package/namespace/library/service; the architect’s primary unit of design.
• Architect’s role re: components: identify them, refine them with developers, and manage the coupling between them.
• Architecture partitioning:
  • Technical partitioning — top-level components organized by technical role (presentation, business, persistence). Aligns with layered architecture.
  • Domain partitioning — top-level components organized by domain/workflow (aligns with DDD “bounded contexts” and, later, microservices). The authors (and the industry trend) lean toward domain partitioning.
  • Conway’s Law and the “Inverse Conway Maneuver”: your system structure mirrors your org’s communication structure — so structure teams to get the architecture you want.
• Ways to identify components: the Actor/Actions approach, the Event Storming approach, the Workflow approach — plus the danger of the “entity trap” (creating one component per database entity, which yields an anemic, CRUD-ish design that isn’t real architecture).
• Component design loop: identify initial components → assign requirements/user stories → analyze roles & responsibilities → analyze characteristics → restructure → repeat (iterative).
• Component granularity/cohesion: too coarse → high internal coupling, hard to deploy independently; too fine → too much inter-component communication.

Trade-offs to argue

Technical vs. domain partitioning is a classic trade-off table: technical partitioning gives clean separation of technical concerns and clear layering, but domain changes ripple across all layers; domain partitioning aligns to how change actually arrives (by feature) and eases the path to distributed services, at the cost of duplicating technical concerns across domains.

Terms to own

component, technical vs. domain partitioning, Conway’s Law / Inverse Conway Maneuver, entity trap, Actor/Actions & Event Storming & Workflow approaches, component granularity.