エピローグ — アーキテクチャは進化する

# 1年間で明確になったモジュール境界
# engines/inventory/  → 独立したデプロイが必要（高頻度変更・高負荷）
# engines/ordering/   → 安定（変更が少ない）
# engines/catalog/    → 中程度（週1-2回変更）
# engines/users/      → 安定（変更が少ない）
# engines/analytics/  → 独立が望ましい（重いバッチ処理）
 
# 1年動かしてみてわかったこと:
# - 在庫管理はブラックフライデーで異常負荷
# - 注文処理はほぼ一定の負荷
# - カタログは検索最適化のためRedis依存が強い

# フェーズ2: モジュール境界を厳格化（現在）
# config/initializers/module_boundaries.rb
 
if Rails.env.development?
  # 直接的な境界越えを検出するルール
  ActiveSupport::Notifications.subscribe('sql.active_record') do |*args|
    event = ActiveSupport::Notifications::Event.new(*args)
    
    # Inventoryモジュールのテーブルに、Ordering以外からアクセスしていたら警告
    if event.payload[:sql].include?('inventory_') && 
       !caller.any? { |c| c.include?('engines/inventory') || c.include?('engines/ordering') }
      Rails.logger.warn "モジュール境界違反: inventory への不正アクセス\n#{caller.first(5).join("\n")}"
    end
  end
end
 
# フェーズ3への準備: 在庫モジュールのAPIを整備
module Inventory
  class Client
    # 将来的にHTTP APIに差し替えられるように
    def self.check_availability(product_id:, quantity:)
      # 今はEngine内のコードを呼ぶ
      Inventory::AvailabilityChecker.new.call(
        product_id: product_id,
        quantity: quantity
      )
    end
    
    def self.reserve(product_id:, quantity:, order_id:)
      Inventory::Reserver.new.call(
        product_id: product_id,
        quantity: quantity,
        order_id: order_id
      )
    end
  end
end

在庫サービス抽出の計画（6週間）:
 
Week 1-2: 準備
  - Inventory::Client の全呼び出し箇所を確認
  - インターフェースを確定（API仕様書を書く）
  - データベースの分離方針を決める
  
Week 3-4: 新サービス開発
  - Rails API として inventory-service を作成
  - Inventory エンジンのコードを移植
  - テストを新サービスに移行
  
Week 5: シャドウモード
  - モノリスと新サービスに両方リクエストを送る
  - 結果を比較して一致を確認
  - 本番ではモノリス側の結果を使用
  
Week 6: カットオーバー
  - Inventory::Client をHTTP APIに差し替え
  - モノリスの在庫テーブルを廃止
  - モニタリングを強化

# 技術的負債のトラッキング
# 「意図的な負債」と「偶発的な負債」を区別する
 
# 意図的な負債の例：ドキュメントに記録する
# ADR-015: OrdersControllerのバリデーション重複を許容する
# 理由: 今週のリリースに間に合わせるため
# 返済計画: 次のスプリントで共通バリデーターに抽出する
# 見積もりコスト: 半日
 
# 偶発的な負債の例：発見次第修正する
# - テストがないコードパス
# - コピペされたビジネスロジック
# - 不明確な変数名

# lib/tasks/tech_debt.rake
namespace :tech_debt do
  desc '技術的負債のレポートを生成'
  task report: :environment do
    puts "=== 技術的負債レポート ==="
    
    # テストカバレッジ
    coverage = `bundle exec rspec --format progress 2>&1 | tail -1`
    puts "テストカバレッジ: #{coverage}"
    
    # 循環複雑度の高いメソッド
    puts "\n複雑なメソッド（flogスコア上位10）:"
    `bundle exec flog --all app/**/*.rb | head -20`.lines.each do |line|
      puts "  #{line}"
    end
    
    # 長すぎるクラス
    puts "\n長すぎるクラス（200行以上）:"
    Dir['app/**/*.rb'].each do |file|
      lines = File.readlines(file).length
      puts "  #{file}: #{lines}行" if lines > 200
    end
  end
end

# spec/architecture/module_boundaries_spec.rb
RSpec.describe 'モジュール境界の遵守' do
  it 'Inventoryモジュールに直接アクセスしていない（Orderingを除く）' do
    # ordering以外のコードがinventoryのクラスに直接アクセスしていないことを確認
    inventory_references = Dir['app/**/*.rb', 'engines/**/*.rb'].filter_map do |file|
      next if file.include?('engines/inventory/')
      next if file.include?('engines/ordering/')  # Orderingは直接アクセス許可
      next if file.include?('spec/')
      
      content = File.read(file)
      file if content.match?(/Inventory::[A-Z]/)
    end
    
    expect(inventory_references).to be_empty,
      "以下のファイルがInventoryモジュールに不正アクセス:\n#{inventory_references.join("\n")}"
  end
  
  it 'Controller層にビジネスロジックがない' do
    thick_controllers = Dir['app/controllers/**/*.rb'].filter_map do |file|
      content = File.read(file)
      # ActiveRecord の複雑なクエリがコントローラにある
      file if content.scan(/\.where\(|\.joins\(|\.includes\(/).length > 3
    end
    
    expect(thick_controllers).to be_empty,
      "Fatなコントローラを検出:\n#{thick_controllers.join("\n")}"
  end
end

# ADR-001 振り返り（6ヶ月後）
 
## 結果
モジュラーモノリスの選択は正しかった。
 
## 良かったこと
- 3ヶ月でのβリリースを達成できた
- チーム全員がコードベースを把握できている
- 単一デプロイによりデプロイ頻度が週3-4回を実現
 
## 課題
- Inventoryモジュールがブラックフライデーで負荷問題
- 18名になり、デプロイの衝突が月2-3回発生
- 管理画面のクエリが遅くなってきた（CQRS導入検討）
 
## 更新
見直しのトリガー「月間ユーザー35万・チーム18名」に達した。
在庫管理のサービス分割プロジェクトを開始する（ADR-016参照）。

# 1年間のインフラ進化
 
初期（3ヶ月前）:
  - ALB → ECS(Rails) → RDS → ElastiCache
  - Lambda: メール・バッチのみ
  - コスト: 月約8万円
 
現在（本番）:
  - ALB → ECS(Rails, 3タスク) → RDS Multi-AZ → ElastiCache Cluster
  - EventBridge + 5つのLambda
  - CloudFront（静的アセット）
  - コスト: 月約35万円
 
計画（6ヶ月後）:
  - 在庫サービスを独立（ECS別クラスター）
  - 読み取りレプリカ（ダッシュボード用）
  - SQS + Lambda（在庫更新の非同期化）
  - コスト見込み: 月約55万円（スケールに見合うと判断）