j5ik2o/okite-ai/cqrs-aggregate-modeling
Claude Code and agent skill by j5ik2o/okite-ai
- community
Checking that the SKILL.md file is still in the repository.
CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。
Install
npx vskill@latest install j5ik2o/okite-ai/cqrs-aggregate-modelingSKILL.md
CQRSによる集約の境界再定義
CQRSを導入すると集約のモデリングが変わる。集約はコマンド実行に必要な最小限の状態のみ保持し、読み取り責務はリードモデルに委譲する。
問題: 肥大化した集約
典型例: Thread集約が1000件のメッセージを保持
更新時の問題
1件のメッセージ追加のために1001件を更新する。 これは集約が「コマンドに必要なデータ」と「クエリに必要なデータ」を区別せずに保持していることが原因。
差分更新の誘惑
差分更新を実装しようとすると、集約の内部実装が複雑化する。どのフィールドが変更されたかを追跡する仕組みが必要になり、ドメインロジックとインフラの関心が混在する。
解決: CQRSによる集約の再設計
核心原則
CQRSを導入すると、集約はコマンド実行に必要な最小限の状態だけ持てばよい。
読み取り責務(クエリ)を集約から完全に除去し、リードモデルに委譲する。その結果、集約はコマンドの検証に必要な情報のみ保持する。
問い: このコマンドの検証に何が必要か?
Thread集約の場合、「メッセージ追加」コマンドの検証に必要なのは:
- 送信者がスレッドのメンバーであること → メンバーIDのリストが必要
- メッセージIDの重複がないこと → メッセージIDのリストが必要
メッセージの本文は不要。 本文は表示(クエリ)のために必要であり、コマンドの検証には関係ない。
再設計後の集約
メッセージ本文を持たないため、集約は大幅に軽量化される。
イベントの設計
イベントにはメッセージ本文を含める(リードモデル構築に必要なため)。ただし、集約の状態復元時にはIDのみを反映する。
リードモデル(Q側)
Before / After 比較
| 観点 | 従来型(非CQRS) | CQRS/ES | |
|---|---|---|---|
| 集約の状態 | メッセージ全文を保持 | メッセージIDのみ保持 | |
| メッセージ追加 | 全件更新 | イベント1件追記 | |
| 読み取り | 集約から直接取得 | リードモデルから取得 | |
| メモリ使用量 | メッセージ数に比例して増大 | ID数に比例(軽量) | |
| ページネーション | 集約内で実装(複雑) | リードモデルのDAO(自然) |
集約の境界再定義の考え方
判断基準: コマンドの検証に必要か?
集約が保持すべきデータを決めるには、各コマンドの検証ロジックを分析する。
具体例: Thread集約の分析
| データ | コマンド検証に必要か | 判断 | |
|---|---|---|---|
| メンバーID一覧 | YES(送信者がメンバーか確認) | 集約に残す | |
| メッセージID一覧 | YES(重複チェック) | 集約に残す | |
| メッセージ本文 | NO(表示のみ) | リードモデルへ | |
| 送信者名 | NO(表示のみ) | リードモデルへ |
強い整合性の再検討
CQRSを導入する際に問うべき:
スレッドとメッセージの関係性に強い整合性は必要か?
- メッセージの追加・表示に「メッセージ本文の即時一貫性」は不要
- メンバーシップの確認にのみ強い一貫性が必要
- 振る舞いがイメージできれば集約の構造が明確になる
大きすぎる集約の兆候と対処
兆候
| 兆候 | 原因 | |
|---|---|---|
| 集約の読み込みが遅い | 不要なデータを大量に保持 | |
| 更新時に全件SQLが発生 | 差分が追跡できない | |
| 集約内にページネーションロジック | クエリ責務が混在 | |
| DTOと集約の構造が酷似 | クエリ用データがそのまま集約に |
対処フロー
関連スキルとの関係
| スキル | 関係 | |
|---|---|---|
aggregate-design | 集約の内部設計原則。本スキルはCQRSによる境界の再定義 | |
cqrs-to-event-sourcing | なぜESが必要か。本スキルはES前提のモデリング変革 | |
cqrs-tradeoffs | 一貫性・可用性のトレードオフ。本スキルはモデリングへの影響 |
レビューチェックリスト
集約の肥大化
- [ ] 集約がクエリ専用データ(表示名、計算結果等)を保持していないか
- [ ] 集約の読み込みにパフォーマンス問題がないか
- [ ] 更新時に不要な全件更新が発生していないか
CQRS/ESによる再設計
- [ ] 各フィールドが「コマンド検証に必要か」で分類されているか
- [ ] クエリ専用データはリードモデルに委譲されているか
- [ ] 集約はIDリスト等の最小限の状態のみ保持しているか
- [ ] イベントにはリードモデル構築に必要な情報がすべて含まれているか
境界の妥当性
- [ ] 集約内のデータすべてに強い整合性が本当に必要か再検討したか
- [ ] 振る舞い(コマンド)に基づいて集約の境界を決めているか
- [ ] 結果整合性で十分なデータを集約から分離しているか
関連スキル(併読推奨)
このスキルを使用する際は、以下のスキルも併せて参照すること:
cqrs-to-event-sourcing: イベントソーシングが集約モデリングを変える理由aggregate-design: CQRS適用前の基本的な集約設計ルールcqrs-tradeoffs: CQRS採用のトレードオフ分析
Security
- Security scanPassed, 100 of 100Pattern checks on the skill's files.
- Model reviewNot runA model review is scheduled for the next rescan.
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/cqrs-aggregate-modeling/SKILL.md
Popularity
- Repository stars
- 80
- Repository forks
- 3
- 7-day trend score
- 22
Stars and forks are for the whole GitHub repository, not this skill alone. Refreshed 8 May 2026, 6 months ago.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/j5ik2o/okite-ai/cqrs-aggregate-modeling)