Cleaning Robots - Volkswagen Digital::Hub

• Cleaning Robots - Volkswagen Digital::Hub
  • Introduction
  • Technologies & Technical Decisions
  • Rich Domain Model
  • Domain Components Description
  • Assumptions & Logic Interpretations
  • Project Structure
  • How to Run]

Introduction

This project implements a robotic navigation engine designed to control autonomous cleaning robots at the Volkswagen Wolfsburg Factory, orchestrating their movements across a rectangular floor grid following precise instruction sets.

Developer: Mauricio Clemente Marina

Technologies & Technical Decisions

• Java 21: Leveraged modern features like Records for immutable data carriers and Enhanced Switch Expressions for cleaner navigation logic.

• Maven: Used for dependency management and build lifecycle.

• JUnit 5 (Jupiter): The primary testing framework. I chose a "No-Mocking" strategy for the core domain to ensure the tests validate real business logic behavior rather than framework configurations.

• Hexagonal Architecture: The project is structured to separate the Domain (core logic and ports) from Infrastructure (Adapters) and Application (Services).

Rich Domain Model

A core requirement and focus of this implementation is the Rich Domain Model. Unlike an "Anemic Domain Model" where logic resides in services, this project encapsulates rules within the objects themselves:

• Self-Validating Records : Coordinates and Pose are not just data holders. They enforce business constraints (e.g., preventing negative coordinates) upon instantiation.

• Stateful Navigation: Instead of complex if/else blocks to handle orientation, I implemented the State Pattern through the Navigator interface. Each orientation (North, East, South, West) is a specialized class that knows exactly how to move or turn, returning a new state.

• Encapsulated Movement : The Robot class manages its own state transitions by coordinating with its Navigator, but it delegates safety checks to the WorkSpace.

Domain Components Description

To ensure a high level of expressiveness, each class in the Domain layer represents a specific concept of the cleaning mission:

• Robot: The main entity. It holds a Navigator and coordinates with the WorkSpace to ensure every instruction is safe before updating its state.

• WorkSpace: Represents the physical area (the floor). It acts as the "Source of Truth" for boundaries and keeps track of all parkedRobots to prevent collisions.

• Navigator (Interface & Implementations): Encapsulates the logic of orientation. Each implementation (FacingNorth, FacingSouth, etc.) defines how the robot behaves when moving or turning based on its current heading.

• Coordinates (Value Object): An immutable representation of a point in 2D space. It ensures that coordinates can never be negative.

• Pose (Value Object): A snapshot of the robot's state, combining its Coordinates and its Heading.

• Heading & Instruction (Enums): Define the language of the domain. Heading represents the cardinal points (N, E, S, W) and Instruction represents the possible commands (L, R, M).

• DeployedRobotInstructions: A simple domain carrier that links a Robot with the specific list of Instructions it must execute.

Benefits of this approach:

1. High Cohesion: Logic is placed next to the data it manipulates.

2. Consistency: Domain rules are enforced at all times, making it impossible to have a robot in an "illegal" state.

3. Testability: Since the logic is within the domain objects, unit tests are straightforward and do not require complex setup or mocking.

Assumptions & Logic Interpretations

During development, I made the following technical assumptions to handle open interpretations of the challenge:

1. Sequential Execution: Robots execute their full set of instructions one by one. The first robot finishes its entire route before the second one starts.

2. Parking & Collisions: Once a robot completes its instructions, it remains "parked" at its final position. This position becomes a permanent obstacle for any subsequent robot entering the field.

3. Fail-Fast Validation: If a robot's MOVE instruction would lead it out of bounds or into a collision with a parked robot, the system throws a custom exception (WorkSpaceLimitException or RobotCollisionException) immediately. The execution for that specific robot stops to guarantee the safety of the unit and the integrity of the workspace.

Project Structure

• Domain: The core of the application. It contains the business entities (Robot, WorkSpace), Value Objects (Pose, Coordinates), the Navigator state logic, and the Inbound Ports (CleanUpUseCase).

• Application: Contains the implementations of the use cases, such as CleaningFactoryService, which orchestrates the domain logic.

• Infrastructure: Handles communication with the outside world. It includes the RobotInputParserMapper for data transformation and the CleaingRobotCliAdpater to manage user interaction via the terminal.

How to Run

1. Build the project:

mvn clean install

2. Run the tests:

mvn test

3 Execute the CLI: Run the main class CleaingRobotCliAdpater.