ストーリー

サービスカタログのデータモデル

エンティティ関連図

サービスカタログのデータモデル:

Domain（ビジネスドメイン）
  └── System（システム）
       ├── Component（サービス）
       │    ├── provides → API
       │    ├── consumes → API
       │    └── dependsOn → Resource
       └── Resource（インフラリソース）

Group（チーム）
  ├── owns → Component
  ├── owns → API
  └── hasMember → User

例:
  Domain: Payments
    └── System: payment-system
         ├── Component: payment-service
         │    ├── provides → payment-api
         │    ├── consumes → user-api
         │    └── dependsOn → payment-db
         ├── Component: payment-worker
         │    └── consumes → payment-api
         └── Resource: payment-db

サービス情報のスキーマ

サービスヘルススコアカード

スコアカードの設計

スコアの算出と表示

ヘルススコアの例:

payment-service: 85/100 ★★★★☆
  ✓ オーナーシップ: 10/10
  ✓ ドキュメント: 10/10
  ✓ API仕様: 10/10
  ✓ CI/CD: 10/10
  △ テスト: 7/10（カバレッジ65%、目標70%）
  ✓ セキュリティ: 15/15
  ✓ 監視: 15/15
  △ 依存関係: 5/10（3つの依存が古い）
  ✗ デプロイ: 3/10（カナリーリリース未導入）

notification-service: 45/100 ★★☆☆☆
  ✓ オーナーシップ: 10/10
  ✗ ドキュメント: 0/10（TechDocsなし）
  ✗ API仕様: 0/10（OpenAPIなし）
  ✓ CI/CD: 10/10
  ✗ テスト: 0/10（テストなし）
  △ セキュリティ: 10/15（Critical 2件未修正）
  △ 監視: 5/15（SLO未定義）
  ✓ 依存関係: 10/10
  ✗ デプロイ: 0/10（手動デプロイ）

スコアの活用

「ヘルススコアは『強制』ではなく『可視化』だ。スコアが低いサービスは改善の動機を自然に得る。ランキングが競争心を刺激し、チーム自らが品質を高める」 — 田中VPoE

依存関係の可視化

サービス依存関係グラフ

依存関係の可視化:

payment-service
  ├── → user-api（API呼び出し）
  ├── → notification-api（イベント送信）
  ├── → payment-db（PostgreSQL）
  └── → payment-redis（Redis）

user-service
  ├── → auth-api（認証）
  └── → user-db（PostgreSQL）

notification-service
  ├── → user-api（ユーザー情報取得）
  ├── → email-provider（外部）
  └── → notification-db（PostgreSQL）

影響分析:
  「user-serviceが停止したら？」
  → payment-service（ユーザー情報取得不可）
  → notification-service（ユーザー情報取得不可）
  影響サービス: 2/25

まとめ

チェックリスト

• サービスカタログのデータモデルを設計できる
• ヘルススコアカードの項目を定義できる
• 依存関係グラフの活用方法を理解した
• サービスカタログの運用方法を把握した

次のステップへ

次は「ソフトウェアテンプレートとスキャフォールディング」を学びます。新規サービスの立ち上げを自動化する仕組みを設計しましょう。

推定読了時間: 30分