Summaries of artifacts, templates, practices, and techniques for agile architecting (DPR-mm) and service design (SDPR-nn).

DPR Git Pages HomeArtifacts Index

Artifact/Template: Components, Responsibilities, Collaborations (CRC) Card

A CRC card describes logical design building blocks on an intermediate level of detail and refinement.

Motivation (Addressed Information Need)

A notation that is well suited for candidate component modeling is the CRC Card format. CRC stands for Components, Responsibilities, Collaborations (CRC) here; you also find Classes or Candidates as the meaning of the first ‘C’. CRC cards allow designers to strike a balance between being precise and being consumable; code interfaces often would be too detailed and boxes-and-arrows diagrams too abstract (depending on the modeling goals and information needs in a given context).

Usage (Produced and Consumed When)

CRC cards primarily serve as specification and documentation tool during Architecture Modeling. Moreover, the cards can support decision-making during component realization, starting with a “make or buy/rent” decision:

Another usage scenario for CRC cards is an interactive workshop or “design thinking” format, sometimes up to a role-playing game: Each participant takes the role of an object/a candidate component (each represented by one CRC card). A ball representing business event and/or program control flow then is thrown around to learn about (and design) data flow, message formats, (a)synchrony, etc. The participants record the resulting collaborations and responsibilities on their CRC cards. These initial versions can then be put in a collaboration tool for further processing — or serve as graphical notes only, accompanying the textual ones (see this blog post) from the workshop.

Template Structure and Notation(s)

An annotated template (with teaser questions) is:

CRC Card Notation Explained

Discussion: The template and the teaser questions deviate from the original CRC format a bit (applying our method engineering rule “do not follow templates blindly, but adopt them to your needs”). In the Responsibilities cell, functions, (externally visible) data, and qualities are mentioned; in the Collaborations cell, both inbound and outbound dependencies can be listed. Note that there is an extra cell asking for previous experiences and realizations with the candidate component (in support of the decision-making use case of CRC cards).


This is an example of a filled out card (an entire layer is described here, rather than a single component in that layer):

CRC Card Notation Example


Any tool that supports table layouts (preferably with the option to merge cells) can be used. Online and offline whiteboards will do too.

Team wikis or Markdown tables are additional options.

Hints and Pitfalls to Avoid

To be able to serve their purpose, CRC cards should be expressive but also easy to understand:

Very busy cards might indicate violations of the single responsibility principle; a large number of nested collaboration chains might indicate an undesired amount of coupling.

Origins and Signs of Use

The original Class, Responsibilities, and Collaborators (CRC) cards were invented by Ward Cunningham (who also invented Wikis and came up with the Technical Debt metaphor) and published in his OOPSLA 1989 paper. They were used for object design and popularized by Rebecca Wirfs-Brock in the Responsibility-Driven Design (RDD) method (@WirfsBrock:2002).

On the architectural level, they are used in Volume 1 of the POSA book series (@Buschmann:1996). See this blog post by Michael Stal from 2006 for background information and rationale. Olaf Zimmermann has been teaching them this way in his “Application Architecture” lecture at HSR/OST since 2013; Michael Keeling features them as Activity 13 in “Design It” (@Keeling:2019).

Usage is straightforward to spot; just look for the keywords “responsibilities” and “collaborations” (or “collaborators”) and a table format that resembles the one introduced above (note that the section on candidate implementation technologies and known uses is optional).

CRC cards can support, and result from, Architecture Modeling activities. The stated responsibilities should trace back to requirements, expressed as User Stories and/or Use Cases and Non-Functional Requirements (NFRs).

Notes and comments in UML and other modeling tools as well as plain text descriptions can be used alternatively, or formatted in such a way that the responsibilities and collaborations come out clearly.

Interface-Responsibility-Interactions (IRI) cards are a similar concept, but applied to interfaces (@Pugh:2006).

More Information

The RDD tutorial explains the original, class-level version and provides additional examples.

Gregor Hohpe explains the difference between “scope” and “abstraction” in his blog post “The Architect’s Path (Part 1 - Model)”. CRC cards have a narrow scope and a conceptual level of abstraction (bottom right quadrant).

RDD and many other methods are compiled and commented on in “Driven by Acronyms”, one of Olaf Zimmermann’s story posts on Medium.

Data Provenance

title: "Design Practice Repository (DPR): CRC Card"
author: Olaf Zimmermann (ZIO)
date: "03, 29, 2021"
copyright: Olaf Zimmermann, 2020-2021 (unless noted otherwise). All rights reserved.
license: Creative Commons Attribution 4.0 International License