On GOV.UK Verify, we’ve adopted a micro-services approach to our architecture, with software systems comprised of groups of services with specific roles and responsibilities. This means we have all the benefits of scaling more easily, rapidly change core functionality and deliver updates without downtime.
We’ve started running a semi-regular exercise based on the concept of Class-Responsibility-Collaboration (CRC) cards, that we feel can be applied to all microservice architectures. This helps to promote knowledge sharing between the team and to test our architecture for potential problem points which we would like to improve upon.
Class Responsibility Collaboration cards
CRC cards were originally introduced as a design tool in Object-Oriented software to help map the roles taken by and the interactions between objects in a system. The cards could either be used when designing new systems or as a way to visualise a legacy system. A set of index cards is generally used as the canvas for the exercise with the aim to produce cards with following layout:
Where:
- Class is the name of the class of the described object
- Responsibilities is a bulleted list of the responsibilities held by the described object
- Collaborators are the class names of the objects which the described object depends on
Our microservices can also be described as a system of objects with defined responsibilities and collaborators. We wanted to see how this might work when scrutinised this way through replacing the class name with the service name.
Running the exercise
Requirements
- A whiteboard or large surface
- pens
- whiteboard
- developers/operations engineers
We have so far run the exercise with the following pattern:
Explain the Exercise
- Gather the team in a place away from distractions
- Ask the team to form groups of 3-4 with mixed experience
- Explain which group of services we would like described (in the case of Verify this could be the Verify Hub or the Document Checking Service)
- Provide some pointers to help with the process:
- Being mistaken is OK
- Focus on the what before the why (discussions around the why’s can come later)
- Move on to another service if stuck
- If unsure about a property then write it down anyway
Produce CRC cards in groups
Leave the groups to work on the cards for a set period of time or until each team is satisfied they have completed the task.
Present and Compare
- Gather the team together again in front of a white board or any other large surface
- Have the groups take turns in presenting a service with its CRC card
- After each card has been presented invite the other groups to provide their own descriptions for that service and come to a consensus as a team on what the CRC card for the service is
Usually, we produce a new set of cards at this stage that we hang close to our workspace and use as an architectural reference.
Highlighting problems and concerns
The result of the exercise may be a set of CRC cards with minimal responsibilities and justified collaborators and no further discussion is needed. However, it is likely that there might be some cards that highlight potential problems (smells), improvements, or that just warrant further discussion. In this case you’ll need to arrange follow-up conversations.
At the end of our first run of this exercise our team was able to identify potential problems with one of our existing services. This prompted us to prioritise some service level refactoring with a goal of more clearly defining the roles of some of our microservices. One of the significant benefits of this was removing a confusing cyclic collaboration between two microservices by moving the services to a more clearly defined set of responsibilities.
You can follow Chris on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
1 comment
Comment by Anthony Green posted on
Today many XP programmers prefer to describe the acronym as 'Candidates, Responsibilities, Collaborators' (e.g.: Nat Pryce and Steve Freeman in 'Growing Object-Oriented Software' http://www.informit.com/articles/article.aspx?p=1400614) so as to emphasis the role of Responsibility-driven design in their approach https://en.wikipedia.org/wiki/Responsibility-driven_design