m09-domain
ドメインモデル、DDDなどのキーワードを基に、エンティティやビジネスルールといった要素を考慮し、システム設計における領域モデリングを支援するSkill。
📜 元の英語説明(参考)
CRITICAL: Use for domain modeling. Triggers: domain model, DDD, domain-driven design, entity, value object, aggregate, repository pattern, business rules, validation, invariant, 领域模型, 领域驱动设计, 业务规则
🇯🇵 日本人クリエイター向け解説
ドメインモデル、DDDなどのキーワードを基に、エンティティやビジネスルールといった要素を考慮し、システム設計における領域モデリングを支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o m09-domain.zip https://jpskill.com/download/9267.zip && unzip -o m09-domain.zip && rm m09-domain.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9267.zip -OutFile "$d\m09-domain.zip"; Expand-Archive "$d\m09-domain.zip" -DestinationPath $d -Force; ri "$d\m09-domain.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
m09-domain.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
m09-domainフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
ドメインモデリング
レイヤー 2: 設計の選択
中核となる質問
この概念はドメインにおいてどのような役割を果たすのか?
コードでモデル化する前に、以下を理解してください。
- それはエンティティ(アイデンティティが重要)ですか、それとも値オブジェクト(交換可能)ですか?
- どのような不変条件を維持する必要がありますか?
- 集約の境界はどこにありますか?
ドメイン概念 → Rust パターン
| ドメイン概念 | Rust パターン | 所有権の含意 |
|---|---|---|
| Entity | struct + Id | 所有、一意のアイデンティティ |
| Value Object | struct + Clone/Copy | 共有可能、不変 |
| Aggregate Root | struct owns children | 明確な所有権ツリー |
| Repository | trait | 永続性を抽象化 |
| Domain Event | enum | 状態の変化をキャプチャ |
| Service | impl block / free fn | ステートレスな操作 |
思考を促すプロンプト
ドメイン型を作成する前に:
-
その概念のアイデンティティは何ですか?
- 一意のアイデンティティが必要 → Entity (Id フィールド)
- 値によって交換可能 → Value Object (Clone/Copy)
-
どのような不変条件を保持する必要がありますか?
- 常に有効 → private フィールド + 検証済みのコンストラクタ
- 状態遷移ルール → type state pattern
-
誰がこのデータを所有していますか?
- 単一の所有者(親) → 所有フィールド
- 共有参照 → Arc/Rc
- 弱参照 → Weak
上方向へのトレース ↑
ドメイン制約へ (レイヤー 3):
"Transaction をどのようにモデル化すべきか?"
↑ 質問: トランザクションを支配するドメインルールは何か?
↑ 確認: domain-fintech (監査、精度要件)
↑ 確認: ビジネスステークホルダー (どのような不変条件か?)
| 設計の質問 | トレース先 | 質問 |
|---|---|---|
| Entity vs Value Object | domain-* | 2つのインスタンスを「同じ」にするものは何か? |
| Aggregate boundaries | domain-* | 何が一緒に整合性が保たれる必要があるか? |
| Validation rules | domain-* | どのようなビジネスルールが適用されるか? |
下方向へのトレース ↓
実装へ (レイヤー 1):
"Entity としてモデル化"
↓ m01-ownership: 所有、一意
↓ m05-type-driven: Id のための Newtype
"Value Object としてモデル化"
↓ m01-ownership: Clone/Copy OK
↓ m05-type-driven: 構築時に検証
"Aggregate としてモデル化"
↓ m01-ownership: 親が子を所有
↓ m02-resource: 集約内で共有する場合は Rc を検討
クイックリファレンス
| DDD 概念 | Rust パターン | 例 |
|---|---|---|
| Value Object | Newtype | struct Email(String); |
| Entity | Struct + ID | struct User { id: UserId, ... } |
| Aggregate | Module boundary | mod order { ... } |
| Repository | Trait | trait UserRepo { fn find(...) } |
| Domain Event | Enum | enum OrderEvent { Created, ... } |
パターンテンプレート
Value Object
struct Email(String);
impl Email {
pub fn new(s: &str) -> Result<Self, ValidationError> {
validate_email(s)?;
Ok(Self(s.to_string()))
}
}
Entity
struct UserId(Uuid);
struct User {
id: UserId,
email: Email,
// ... other fields
}
impl PartialEq for User {
fn eq(&self, other: &Self) -> bool {
self.id == other.id // Identity equality
}
}
Aggregate
mod order {
pub struct Order {
id: OrderId,
items: Vec<OrderItem>, // Owned children
// ...
}
impl Order {
pub fn add_item(&mut self, item: OrderItem) {
// Enforce aggregate invariants
}
}
}
よくある間違い
| 間違い | なぜ間違っているのか | より良い方法 |
|---|---|---|
| Primitive obsession | 型安全ではない | Newtype ラッパー |
| Public フィールドと不変条件 | 不変条件が破られる | Private + アクセサ |
| Leaked aggregate internals | カプセル化が壊れる | ルートのメソッド |
| String for semantic types | 検証がない | 検証済みの newtype |
関連スキル
| いつ | 参照 |
|---|---|
| 型駆動の実装 | m05-type-driven |
| 集約のための所有権 | m01-ownership |
| ドメインエラー処理 | m13-domain-error |
| 特定のドメインルール | domain-* |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Domain Modeling
Layer 2: Design Choices
Core Question
What is this concept's role in the domain?
Before modeling in code, understand:
- Is it an Entity (identity matters) or Value Object (interchangeable)?
- What invariants must be maintained?
- Where are the aggregate boundaries?
Domain Concept → Rust Pattern
| Domain Concept | Rust Pattern | Ownership Implication |
|---|---|---|
| Entity | struct + Id | Owned, unique identity |
| Value Object | struct + Clone/Copy | Shareable, immutable |
| Aggregate Root | struct owns children | Clear ownership tree |
| Repository | trait | Abstracts persistence |
| Domain Event | enum | Captures state changes |
| Service | impl block / free fn | Stateless operations |
Thinking Prompt
Before creating a domain type:
-
What's the concept's identity?
- Needs unique identity → Entity (Id field)
- Interchangeable by value → Value Object (Clone/Copy)
-
What invariants must hold?
- Always valid → private fields + validated constructor
- Transition rules → type state pattern
-
Who owns this data?
- Single owner (parent) → owned field
- Shared reference → Arc/Rc
- Weak reference → Weak
Trace Up ↑
To domain constraints (Layer 3):
"How should I model a Transaction?"
↑ Ask: What domain rules govern transactions?
↑ Check: domain-fintech (audit, precision requirements)
↑ Check: Business stakeholders (what invariants?)
| Design Question | Trace To | Ask |
|---|---|---|
| Entity vs Value Object | domain-* | What makes two instances "the same"? |
| Aggregate boundaries | domain-* | What must be consistent together? |
| Validation rules | domain-* | What business rules apply? |
Trace Down ↓
To implementation (Layer 1):
"Model as Entity"
↓ m01-ownership: Owned, unique
↓ m05-type-driven: Newtype for Id
"Model as Value Object"
↓ m01-ownership: Clone/Copy OK
↓ m05-type-driven: Validate at construction
"Model as Aggregate"
↓ m01-ownership: Parent owns children
↓ m02-resource: Consider Rc for shared within aggregate
Quick Reference
| DDD Concept | Rust Pattern | Example |
|---|---|---|
| Value Object | Newtype | struct Email(String); |
| Entity | Struct + ID | struct User { id: UserId, ... } |
| Aggregate | Module boundary | mod order { ... } |
| Repository | Trait | trait UserRepo { fn find(...) } |
| Domain Event | Enum | enum OrderEvent { Created, ... } |
Pattern Templates
Value Object
struct Email(String);
impl Email {
pub fn new(s: &str) -> Result<Self, ValidationError> {
validate_email(s)?;
Ok(Self(s.to_string()))
}
}
Entity
struct UserId(Uuid);
struct User {
id: UserId,
email: Email,
// ... other fields
}
impl PartialEq for User {
fn eq(&self, other: &Self) -> bool {
self.id == other.id // Identity equality
}
}
Aggregate
mod order {
pub struct Order {
id: OrderId,
items: Vec<OrderItem>, // Owned children
// ...
}
impl Order {
pub fn add_item(&mut self, item: OrderItem) {
// Enforce aggregate invariants
}
}
}
Common Mistakes
| Mistake | Why Wrong | Better |
|---|---|---|
| Primitive obsession | No type safety | Newtype wrappers |
| Public fields with invariants | Invariants violated | Private + accessor |
| Leaked aggregate internals | Broken encapsulation | Methods on root |
| String for semantic types | No validation | Validated newtype |
Related Skills
| When | See |
|---|---|
| Type-driven implementation | m05-type-driven |
| Ownership for aggregates | m01-ownership |
| Domain error handling | m13-domain-error |
| Specific domain rules | domain-* |