Skip to content
Snippets Groups Projects
Code owners
Assign users and groups as approvers for specific file changes. Learn more.

ADR-001: Clarifying Control Flow via Abstract Rover Interface

Context and Problem Statement

In the design of the Mars exploration software system, ambiguity existed in how the key entities—MissionControl, Rover, and Mars—interact. Initially, implementations had the Rover directly accessing and modifying Mars-related data, implying a direct control relationship. However, this contradicts the operational reality where MissionControl issues commands to the Rover, which then interacts with Mars.

This architectural confusion led to violations of separation of concerns and incorrect system assumptions, identified during early integration testing.

Decision Drivers

  • Reflect the real-world control flow between components
  • Improve maintainability and reduce tight coupling
  • Enable flexibility for multiple Rover implementations

Considered Options

  • Make the Rover class abstract, allowing MissionControl to interact with Mars via an interface provided by the Rover.
  • Retain the current design with direct associations between Rover and Mars.

Decision Outcome

We decided to make the Rover class abstract to serve as a clear interface between MissionControl and Mars, improving architectural separation and reflecting real-world operational flows.

Pros and Cons of the Options

Make Rover Abstract

Pros:

  • Matches domain reality: MissionControlRoverMars
  • Promotes separation of responsibilities
  • Enables extensibility for different rover models or missions

Cons:

  • Adds abstraction complexity
  • Increases burden of interface maintenance
  • Shared resource access (e.g., terrain data, logs) must now be explicitly managed through the interface

Retain Direct Associations

Pros:

  • Simpler to implement
  • Requires fewer changes to existing code

Cons:

  • Misrepresents real-world responsibilities
  • Leads to tight coupling and potential logic duplication
  • Makes testing and reuse more difficult

Consequences

Positive

  • Enforces proper boundaries and encapsulation
  • Reduces coupling between MissionControl and Mars
  • Enables future rover variants without modifying mission logic

Negative

  • Increased complexity in interface design and implementation
  • Requires careful coordination for shared state and resource access