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, allowingMissionControl
to interact withMars
via an interface provided by theRover
. - Retain the current design with direct associations between
Rover
andMars
.
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:
MissionControl
→Rover
→Mars
- 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
andMars
- 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