Implementation

Implementation Overview

Once the architecture of the RoboFlow system is in place, the next step is to implement the individual services - each of which represents a specific capability.

The Workbench is designed to support this transition from design to implementation. It allows you to go from high-level system architecture down to the specification of individual services without losing alignment along the way. All projects are structured around Domain-Driven Design (DDD) principles, so technical implementation stays tied to the business concepts.

To show you what that looks like in practice, we will walk through part of the implementation behind RoboFlow. Customers use the webshop to browse, select parts, and place orders. The system is composed of multiple microservices, and each one is modeled and implemented in the Workbench.

This article gives you a quick look into the implementation of one of these services - the Checkout Service - and how the Workbench helps structure and document its design, API, and integrations. This is not a full implementation walkthrough but a window into how business logic becomes working software in a consistent, collaborative, and model-driven way.

At this point, you know all the details behind the architecture of our RoboFlow and you have seen the flow of creating an architectural software system. Now, we will go deeper into the implementation of the B2B webshop. We have created a workspace that has all the components of the RoboFlow project as you can see below.

Let's go into the details of one of our services, for example the Checkout service.

Checkout Service

The Checkout Service is one of several services that make up the RoboFlow webshop. It is implemented as a Domain Service Project — a project type focused on capturing the detailed design of a service in a standardized and structured way. This is the design pillar of the Workbench, which typically follows the architecture phase as the next step: defining how the service will be implemented to meet the requirements. Similar to the architecture project, the overview page has the documentation section where you get an idea of the purpose of this service as well as the necessary documentation, also as you see from the meta information, it also resides in my git repository. This type of service is organized into layers , API, design and integration which you see on the left side, this Organization is called Namespaces. It also integrates with your exiting CI/CD infrastructure.

An overview of the Checkout service - Documentation and meta data.

The API namespace allows you to design and upload your existing API definitions and the Workbench will generate the necessary classes and code for you

The domain namespace is the core of the service that has the business design, here you can design and re-use entities, properties, events that are consumed or fired

Select the service you want to integrate with and simply upload the related API definitions to have a successful integration as you can see here

In RoboFlow, some services also demonstrate more advanced or exploratory capabilities. These aren't necessarily core to every application but are useful to highlight what's possible with the Workbench. One such example is our implementation of product recommendations.

A look at advanced capabilities: Product recommendations with GenAI

As we had a requirement in our RoboFlow project to recommend products to users based on their order history, we have implemented the product recommendation service as a retrieval-augment generation (RAG) component with a local LLM model integration.

If you're interested in how GenAI capabilities like this are integrated, follow the dedicated How-To: Integrate GenAI guide for a step-by-step walkthrough.

This gives you a sense of how high-level architecture translates into working, structured implementations using the Workbench. From here, you can explore more detailed tutorials or dive into other services in the RoboFlow system to see how different parts come together.