De objeto de estudo a produto real

1. O problema e os requisitos

# O pesadelo começa a escalar
def system_prompt
  if Current.user.politician?
    "Você é um estrategista político focado em campanhas eleitorais..."
  else
    "Você é um especialista em marketing..."
  end
end

• Isolamento de regras: Cada vertical tem seus próprios planos, templates, integrações e vocabulário. Esse conhecimento precisava parar de vazar.
• Mesmo motor: Editor de sites, gestão de leads, infraestrutura: tudo continua sendo exatamente o mesmo. A diferença mora na configuração e nas regras, não no fluxo da aplicação. Nada de repositórios separados, engines ou a tentação sempre presente de fatiar tudo em microsserviços.
• Escalabilidade técnica: Adicionar um vertical novo devia ser uma mudança localizada, não uma caça ao tesouro pelo repositório inteiro.

2. As decisões principais

                    Request
                       │
                       ▼
             ApplicationController
                       │
                       ▼
              Verticals::Registry
                       │
                resolve(context)
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       General      Politico    Transportadora
          │            │            │
          └────────────┼────────────┘
                       ▼
                Current.vertical
                       │
          ┌────────────┼─────────────┐
          ▼            ▼             ▼
        Views       Billing          AI

module Verticals
  class Base
    # Identificação
    def self.key; raise NotImplementedError; end
    def self.subdomain; raise NotImplementedError; end

    # UI & Funcionalidades
    def self.available_sections; raise NotImplementedError; end
    def self.page_templates; raise NotImplementedError; end

    # Billing
    def self.plans; raise NotImplementedError; end

    # Inteligência Artificial
    def self.ai_system_prompt; raise NotImplementedError; end
  end
end

# app/verticals/politico.rb
module Verticals
  class Politico < Base
    def self.key = :politico
    def self.subdomain = "politico"

    def self.available_sections
      # O vertical limita as seções disponíveis no criador de sites
      [:hero, :biography, :agenda, :campaign_proposals, :donation, :volunteer]
    end

    def self.plans
      # Os planos são versionados junto ao vertical porque representam
      # a oferta estrutural comercial daquele produto.
      {
        bronze_tier: { pages: 3, price: 9000, ... },
        silver_tier: { pages: 10, price: 19000, ... }
      }
    end

    def self.ai_system_prompt
      "Você é um estrategista político focado em campanhas eleitorais..."
    end
  end
end

Rails.autoloaders.main.push_dir(
  Rails.root.join("app/verticals"),
  namespace: Verticals
)

class ApplicationController < ActionController::Base
  before_action :set_current_vertical

  private

  def set_current_vertical
    Current.vertical = Verticals::Registry.resolve(
      subdomain: request.subdomain,
      user: Current.user
    )
  end
end

3. Trade-offs e alternativas consideradas

• Configuração via JSON/YAML: Resolveria bem a parte de dados, mas comportamento é outra história. Algumas configurações precisam ser compostas, derivadas, ou compartilhar lógica comum entre si. Um arquivo estático não faz isso sozinho, me obrigando a construir uma camada extra só para validar e interpretar o próprio contrato. Preferi já nascer em Ruby.
• Rails Engines: Fariam sentido se os verticais fossem domínios independentes de verdade, com código, rotas e responsabilidades isoladas. Não é o caso aqui. Os verticais do Sectify ainda compartilham o mesmo modelo de dados e a maior parte do fluxo da aplicação, então separar em engines só adicionaria complexidade de manutenção sem resolver nada que já não estivesse resolvido.
• STI no model de User: Tentador à primeira vista, errado na prática. O vertical não é um subtipo de usuário, mas sim o contexto de produto em que aquele usuário está operando. Amarrar regras de interface e faturamento à classe do Active Record seria vazar domínio comercial para a camada errada, exatamente o problema que eu estava tentando resolver, só que disfarçado.

4. Execução da refatoração: "Comendo o boi a bife"

1. A fundação: Criação do Registry, do contrato (Base) e a migration renomeando a coluna industry para vertical. 
2. Roteamento e autenticação: Injeção do Current.vertical no ciclo de vida da requisição e roteamento dinâmico no routes.rb, iterando sobre os verticais para gerar constraints por subdomínio. Também ajustei a autenticação para funcionar cross-subdomain: se um usuário loga no subdomínio geral, mas a conta está atrelada ao vertical Político, ele é redirecionado automaticamente, sem precisar entender por que caiu no lugar errado.
3. Apresentação (views e I18n): Remoção dos ifs nas views, um por um. A parte mais valiosa disso tudo foi extrair a terminologia: dicionários isolados como locales/verticals/politico.pt-BR.yml mantiveram o vocabulário de cada vertical fora do core, onde ele nunca deveria ter estado.
4. Camada de serviços: Refatoração do SchemaBuilderService, responsável pela composição do schema usado pela IA, e dos controllers de assinatura, agora consultando dinamicamente a configuração do vertical ativo em vez de perguntar quem é o usuário.
5. A grande limpeza: Um PR final, destrutivo e satisfatório (desses que dá gosto de mergear), dedicado a rodar grep -r "politician?" e caçar os resíduos que sobraram.

Verticals::Registry.each_with_subdomain do |vertical|
  constraints subdomain: vertical.subdomain do
    get "/", to: "verticals/home#index"
  end
end

5. O que ficou e o próximo teste

RSpec.shared_examples "a vertical" do
  it "complies with the structural contract" do
    expect(described_class.key).to be_a(Symbol)
    # General não tem subdomínio explícito
    expect(described_class.subdomain).to be_present.or be_nil
    expect(described_class.available_sections).to all(be_a(Symbol))

    # Valida que todos os planos têm estrutura de preço e páginas
    expect(described_class.plans.values).to all(
      include(:pages, :price)
    )
  end
end

# Validando o contrato de um novo vertical em poucas linhas:
RSpec.describe Verticals::Transportadora do
  it_behaves_like "a vertical"
end

# ApplicationController
before_action :set_view_path

private

def set_view_path
  prepend_view_path("app/views/verticals/#{Current.vertical.key}")
end