We have three sets of data structures, the ones used in the API requests and responses, the internal objects, and the k8s objects we create from those.

This task is to split those three sets, creating a clear distinction between them and allowing us to modularize the application.

• API layer:

This contains the logic to validate API requests, and how to create business model objects from them

• Core (business) layer:

This contains our internal objects (ScheduledJob, OneOffJob, ContinuousJob, ...) and has logic related only to how to manage those.

• Runtime layer:

This will have the logic on how to instantiate the business layer objects into k8s, using an abstract class to be able to easily change the infa layer in the future:

from abc import ABC, abstractmethod

class Engine(ABC):
   @abstractmethod
   def run_continuous_job(self, continuous_job: ContinuousJob) -> RunResult:
      pass

   @abstractmethod
   def run_scheduled_job(self, scheduled_job: ScheduledJob) -> RunResult:
      pass
...


class K8sEngine(Engine):
    def run_continuous_job(self, continuous_job: ContinuousJob) -> RunResult:
        ... do stuff on k8s to get the job running

• Storage layer:

This serves the abstraction used to persist objects (currently on k8s), might use it's own datastructures (ex. k8s custom resources)

A diagram of how the layers should interact with each other (from https://docs.google.com/document/d/1hkUMuJ3JFszCWqGkA1vfLoQKnae4YND29oORppN7lKo/edit?tab=t.0):

This is maximized to allow responsibility separation (API deals with the API interfacing, core with the business logic, storage with how to persist, ...) and keep cohesion to a maximum (if you change some code, the extra code that needs changing is as close to it as possible) while allowing for plugability of implementation details (http api, k8s runtime, k8s storage, ...).