design code suggestions?

parser_worker.rb

class ToolParserWorker
  include Sidekiq::Worker

  def perform(scan)

    ## On a near futute NessusParser will die an become a ParserFactory based on scan tool type
    report = NessusParser.execute(self.file.current_path) # execute returns a Report object

    scan.update_parsed_report(report.to_json) # scan is mongo document
  end
end

O problema que existe nessa solução é que de qualquer forma o Model ficará acoplando com o Parser, que é justamente o que estou querendo evitar. O NessusParser é só um, de um conjunto de parsers de xml, que eu não queria que tivessem dependências com a regra da aplicação, ou seja, só faz parsear o xml e retorna um objeto report. O que motivou a criar os parsers próprios e não utilizar os existentes, foi o os módules de parser terem dependência com ORM.

Dado esse cenário, utilizando a sugestão do @pellegrino, o que pensei:

class ToolParserWorker
  include Sidekiq::Worker

  def perform(scan_id)
    UpdateScanParser.new(scan_id).parse
  end
end

class UpdateScanParser
  def initialize(scan_id)
    @scan_id = scan_id
  end

  def parse
    report = parser.parse(scan)
    scan.update_parsed_report(report.to_json)
  end

  private
  def scan
    scan ||= Scan.find(id: @scan_id)
  end

  def parser
    parser ||= ParserFactory.instance(scan.tool)
  end
end

class NessusParser
  def execute(path)
     # ....
     return report
  end
end

class Scan
  #...
  def update_parsed_report(json)
    self.parsed_document = json
    sef.save!
  end
end

Dessa forma, fica obscuro para que está chamando UpdateScanParser que ele chama uma fábrica de Parser internamente, o que me incomoda é que método UpdateScanParser#parse, parece desrespeitar o SRP, mas ao mesmo tempo não acho que deveria criar mais uma classe pra tratar a o update externamente.

@tapajos coloquei o que o update_parsed_report faz ;)

Não tinha entendido que haveriam vários parsers, neste caso fico com a solução do @pellegrino, reescrita pelo @caike