Skip to content

Minimize/DRY Service Layer in Remote Development ROP domain architecture

MR: Refactor Remote Dev to a single common service ... (!156660 - merged)

Description

Based on discussions started in this thread, we originally concluded that there is no value in preserving a traditional Service tier in the ROP-based Remote Development architecture.

Original Reasons:

  • The ROP architecture and domain layer already serves the purpose of cohesively containing the core domain logic, which is normally filled by the service tier
  • Service tier serves no purpose, it's essentially just useless glue code
  • No other domains depend upon the Remote Development domain, and thus there is no need to preserve the standard interface of a service layer for cross-domain interactions. And even if it did, we would still likely want to maintain loose coupling via some other means (e.g. event architecture) rather than directly coupling to class calls.
  • It makes the architecture easier to understand
  • It's less code to write when implementing new features and new ROP chains.

UPDATED APPROACH:

  • However, in the future, there may be a need to invoke Remote Dev Workpaces from other domains.
  • There is also some benefit to keeping some layer between the APIs and Main ROP classes, to hold common logic, such as injecting settings and logger to all ROP chains.
  • Also, having NO service layer at all may be confusing for maintainers and contributors.
  • Therefore, we will instead attempt to minimize and DRY up the Service layer, ideally by having only a single common service class, which can be used for any different API or subdomain within the remote development domain.
  • This single-class approach addresses the big concerns from the original reasons, but only as much as is useful, and still preserves this standard architectural layer as is expected within the GitLab monolith.

Implementation Details

See the MR at Refactor Remote Dev to a single common service ... (!156660 - merged) for more implementation details.

Acceptance Criteria

  • Refactor the service tier to a single class.
  • Update the ee/lib/remote_development/README.rb as needed.

Technical Requirements

See description

Edited by Chad Woolley