問題点一覧:

総合評価: 2.5/5 — テスト容易性と変更容易性に重大な問題あり

改善後の構造:
src/
├── modules/
│   ├── ordering/
│   │   ├── domain/
│   │   │   ├── entities/
│   │   │   │   ├── Order.ts            # Aggregate Root
│   │   │   │   └── OrderItem.ts
│   │   │   ├── value-objects/
│   │   │   │   ├── OrderId.ts
│   │   │   │   └── Money.ts
│   │   │   └── ports/
│   │   │       ├── in/
│   │   │       │   ├── CreateOrderUseCase.ts
│   │   │       │   └── CancelOrderUseCase.ts
│   │   │       └── out/
│   │   │           ├── OrderRepository.ts
│   │   │           └── PaymentGateway.ts
│   │   ├── application/
│   │   │   └── CreateOrderUseCaseImpl.ts
│   │   ├── adapters/
│   │   │   ├── in/OrderController.ts
│   │   │   └── out/
│   │   │       ├── PrismaOrderRepository.ts
│   │   │       ├── InMemoryOrderRepository.ts
│   │   │       └── StripePaymentGateway.ts
│   │   └── index.ts                     # 公開API
│   └── payment/
│       └── ...
├── shared/
│   └── domain-event.ts
├── composition-root.ts
└── main.ts

主な改善点:

1. ドメインモデルの隔離（Orderにビジネスロジックを移動）
2. Port/Adapterによる外部依存の分離
3. DIによるテスト容易性の確保
4. モジュラーモノリスでBC間の境界を明確化
5. 型安全なInput/Output型の導入

// 1. 依存性ルールチェック
describe('依存性ルール', () => {
  it('domain層はadapters層に依存しない', () => {
    const domainFiles = getAllFilesIn('src/modules/ordering/domain/');
    for (const file of domainFiles) {
      const imports = getImports(file);
      expect(imports.filter(i => i.includes('/adapters/'))).toEqual([]);
    }
  });

  it('domain層は外部ライブラリに依存しない', () => {
    const domainFiles = getAllFilesIn('src/modules/ordering/domain/');
    for (const file of domainFiles) {
      const content = readFileSync(file, 'utf-8');
      expect(content).not.toContain('from "express"');
      expect(content).not.toContain('from "@prisma/client"');
      expect(content).not.toContain('from "stripe"');
    }
  });
});

// 2. モジュール境界チェック
describe('モジュール境界', () => {
  it('他モジュールの内部に直接アクセスしない', () => {
    const orderingFiles = getAllFilesIn('src/modules/ordering/');
    for (const file of orderingFiles) {
      const imports = getImports(file);
      const directPaymentImports = imports.filter(i =>
        i.includes('modules/payment/domain/') ||
        i.includes('modules/payment/application/') ||
        i.includes('modules/payment/adapters/')
      );
      expect(directPaymentImports).toEqual([]);
    }
  });
});

// 3. any型禁止チェック
describe('型安全性', () => {
  it('domain層にany型が存在しない', () => {
    const domainFiles = getAllFilesIn('src/modules/*/domain/');
    for (const file of domainFiles) {
      const content = readFileSync(file, 'utf-8');
      // コメント行を除外してanyの使用をチェック
      const codeLines = content.split('\n')
        .filter(l => !l.trim().startsWith('//'));
      const anyUsages = codeLines.filter(l => /:\s*any\b/.test(l));
      expect(anyUsages).toEqual([]);
    }
  });
});

// 4. テスト実行速度チェック
describe('テスト速度', () => {
  it('ドメインテストは5秒以内に完了する', () => {
    const start = Date.now();
    // ドメインテストを実行
    execSync('npx jest --testPathPattern=domain --silent');
    expect(Date.now() - start).toBeLessThan(5000);
  });
});

# ADR-004: BookMartのモジュラーモノリス + ヘキサゴナルアーキテクチャへの移行

## ステータス
提案中

## コンテキスト
BookMartのECサイトはレイヤードアーキテクチャで構築されているが、
以下の問題が顕在化している:
- 変更の影響範囲が予測困難
- DB/外部API接続なしにテスト不可（テスト実行に5分以上）
- ビジネスロジックがService層に分散し、把握が困難

チーム規模は8名で、マイクロサービスは運用負荷の観点から時期尚早。

## 決定
モジュラーモノリス + ヘキサゴナルアーキテクチャ + DDDに移行する。

## 理由
- テスト容易性の大幅な改善（InMemory Adapterで独立テスト可能）
- 変更容易性の向上（BCごとのモジュール分離で影響範囲が限定）
- ドメインモデルの充実（貧血モデルからリッチモデルへ）
- 将来のマイクロサービス化への移行パスを確保
- チーム規模に適した複雑さ

## 却下した選択肢
- マイクロサービス: 8名チームには運用コストが高い
- レイヤードの改善のみ: 根本的な構造問題が解決しない
- CQRS + イベントソーシング: 現段階ではオーバーエンジニアリング

## トレードオフ
- 得るもの: テスト容易性、変更容易性、ドメインの明確化
- 失うもの: 初期移行コスト（推定2ヶ月）、学習コスト、一部パフォーマンス

## 結果
（移行完了後に記載予定）

Phase 1（2週間）: 基盤整備
- ディレクトリ構造の変更
- Composition Rootの導入
- フィットネス関数のCI設定

Phase 2（3週間）: 注文BC（最も問題が大きいモジュール）
- Order Aggregate の設計・実装
- Use Caseの分離
- Port/Adapterの定義
- InMemoryRepositoryでのテスト追加

Phase 3（2週間）: 決済BC
- PaymentGateway Portの定義
- StripePaymentGateway Adapterの分離
- テストでのStub化

Phase 4（1週間）: 統合・検証
- 全モジュール間の結合テスト
- パフォーマンス回帰テスト
- フィットネス関数の全項目パス確認

移行原則:
- Strangler Figパターン: 新機能は新アーキテクチャで、既存は段階的に移行
- 常にデプロイ可能な状態を維持する
- 各Phase完了後にチーム内レビュー