Scenario — RoboFlow

Every block in this demo runs against the same reference application: RoboFlow, a fictional B2B webshop for robotics parts. It's the same scenario used across the public trial experiences — so if you've completed one of those, or a customer has, the system will already feel familiar.

Using one consistent scenario across all three blocks is what makes the story hold together: the architectural decision a developer follows in block one is attached to the same Payment Service the audience sees generate a full microservice in block two, and decomposed from the same business requirement in block three. Three different personas, three different pain points, one shared design model underneath.

Before presenting, make sure you can find your way around this system — which services exist, how they relate, and where the three services central to the demo (Checkout, Payment, Gift Card) sit in the architecture.

The RoboFlow reference application

The trials in this section are built around RoboFlow — a fictional B2B webshop for robotics parts that serves as the reference application across all trial experiences. If you want to find out about RoboFlow's ambitions and requirements, you can head to the RoboFlow overview page for a quick introduction.

RoboFlow's system is composed of multiple microservices, each designed and documented in the Workbench. The starting point is an architecture project — a high-level view of the system that shows which services exist, how they relate, and what responsibilities they carry. RoboFlow's architecture is modelled using C4 notation, one of the modelling languages IBM DevOps Solution Workbench supports out of the box.

The diagram below is the Container Diagram (Level 2) of the RoboFlow system in the RoboFlow architecture project — one level below the overall system context (L1), showing the individual services and their relationships. You can also open it directly in the Workbench.

The system includes a WebShop Frontend, a Basket Service, a Checkout Service, a Payment Service, and others. Three services are central to the trials:

• Checkout Service — orchestrates the checkout flow, applies discounts, and initiates payment
• Payment Service — handles all payment processing and integrates with external payment providers
• Gift Card Service — manages gift card balances, validates voucher codes, and tracks redemptions

Each service usually has its own service project in the Workbench — a separate, more detailed specification that defines the service's boundaries, domain model, interfaces, and the architectural decisions that apply to it. This is where the real design work happens.

Explore a service

As an example, let's look at the Checkout Service.

Select the Checkout Service on the L2 diagram and in the sidebar on the right (you might need to expand it) navigate to the Loop tab.

Find the Workbench project and "Open in new tab". This will open the service project where the design details of the Checkout Service are modelled and documented.

In the left navigation bar, open Diagrams and then open the "Checkout Service component diagram".

You can now explore the Component Diagram (Level 3 in the C4 model) of the Checkout Service.