jpskill.com
📦 その他 コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して m09-domain.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → m09-domain フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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 ステートレスな操作

思考を促すプロンプト

ドメイン型を作成する前に:

  1. その概念のアイデンティティは何ですか?

    • 一意のアイデンティティが必要 → Entity (Id フィールド)
    • 値によって交換可能 → Value Object (Clone/Copy)
  2. どのような不変条件を保持する必要がありますか?

    • 常に有効 → private フィールド + 検証済みのコンストラクタ
    • 状態遷移ルール → type state pattern
  3. 誰がこのデータを所有していますか?

    • 単一の所有者(親) → 所有フィールド
    • 共有参照 → 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:

  1. What's the concept's identity?

    • Needs unique identity → Entity (Id field)
    • Interchangeable by value → Value Object (Clone/Copy)
  2. What invariants must hold?

    • Always valid → private fields + validated constructor
    • Transition rules → type state pattern
  3. 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-*