DDD Boundaries Review

DO NOT recommend splitting code into new contexts unless the business boundary is explicit enough to name.
DO NOT treat every large module as a bounded context automatically.
ALWAYS identify the leaked language or ownership conflict before proposing structural changes.

# Find references from one context into another
rg 'Billing.*Fleet|Fleet.*Billing' app/

# Find cross-namespace constant usage
rg 'Billing::[A-Z]' app/services/fleet/
rg 'Fleet::[A-Z]' app/services/billing/

# Find callbacks that touch foreign concepts
rg 'after_(create|update|save).*Job|after_(create|update|save).*Mailer' app/models/

# app/services/billing/invoice_service.rb
class Billing::InvoiceService
  def call(reservation_id)
    reservation = Fleet::Reservation.find(reservation_id)
    reservation.update!(status: :invoiced)  # Billing mutating Fleet state
    create_invoice(reservation)
  end
end

# Fleet publishes an outcome; Billing subscribes via a job or hook
class Fleet::Reservation < ApplicationRecord
  def complete!
    update!(status: :completed)
    ReservationCompletedJob.perform_later(id)  # Fire-and-forget event
  end
end

# app/services/billing/invoice_service.rb — no Fleet constants
class Billing::InvoiceService
  def call(reservation_id:, amount_cents:)
    create_invoice(reservation_id:, amount_cents:)
  end
end

Severity: High
Contexts: Billing → Fleet
Leaked term: reservation.update!(status: :invoiced)
Risk: Billing owns Fleet state transitions. Changes to Fleet lifecycle break Billing silently.
Smallest credible fix: Fleet emits ReservationCompleted event; Billing reacts without touching Fleet models.