jpskill.com
🛠️ 開発・MCP コミュニティ

architecture-ddd

ソフトウェアアーキテクチャにドメイン駆動設計のパターンや概念、ガイダンスを適用するSkill。

📜 元の英語説明(参考)

Domain-Driven Design patterns, concepts, and guidance for software architecture.

🇯🇵 日本人クリエイター向け解説

一言でいうと

ソフトウェアアーキテクチャにドメイン駆動設計のパターンや概念、ガイダンスを適用するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⬇ このSkillをダウンロード(.skill) 元のソースを見る ↗

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

🎯 この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-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

スキル: アーキテクチャ & DDD マスターガイド

このドキュメントは、プロジェクトにおけるドメイン駆動設計（DDD）アーキテクチャと厳格なレイヤー境界を定義します。

🏛️ 1. レイヤードアーキテクチャ（原則）

依存関係は内側に向かって流れる必要があります: プレゼンテーション → アプリケーション → ドメイン ← インフラストラクチャ。

🔴 ドメイン層 (src/app/domain/)

  • 純粋性: フレームワークへの依存はゼロです（Angular、Firebase、RxJS は使用しません）。
  • エンティティ: 最小限で、意図のないモデルです。
  • 値オブジェクト: 不変で、作成時に検証されます。
  • リポジトリ: インターフェースのみです（ポート）。
  • 集約: トランザクション境界です。
  • ドメインイベント: 発生した不変の「事実」です。

🟡 アプリケーション層 (src/app/application/)

  • オーケストレーション: ユースケース（ハンドラー）を実装します。
  • 状態: NgRx Signals (Store) が信頼できる情報源です。
  • マッパー: ドメイン ↔ DTO / ViewModel の変換を行います。
  • ポート: リポジトリとサービスインターフェースを定義します。

🔵 インフラストラクチャ層 (src/app/infrastructure/)

  • アダプター: アプリケーション/ドメイン層で定義されたインターフェースを実装します。
  • 技術的要素: Firebase、HTTP、永続化、ロギング、外部 SDK などです。
  • DTOs: この層に限定され、プレゼンテーション層やドメイン層に漏洩することはありません。

🟢 プレゼンテーション層 (src/app/presentation/)

  • UI のみ: ビジネスロジックは含みません。
  • シグナル: ストアからのシグナルを消費します。
  • スタンドアロン: すべてのコンポーネントはスタンドアロン + ゾーンレスです。

🧩 2. 戦術的 DDD パターン

リポジトリパターン

  • インターフェースは ドメイン または アプリケーション で定義されます。
  • 実装は インフラストラクチャ に隠蔽されます。
  • 疎結合を確実にするため、InjectionToken を介して注入されます。

ドメインサービス

  • 複数のエンティティが関わるロジックや、いずれかのエンティティに自然に収まらないロジックに使用されます。
  • 純粋さを保つ必要があります（I/O なし）。

イベント駆動フロー

  1. 追加: コマンドの結果をストア/データベースに永続化します。
  2. 発行: EventBus を介してイベントを発行します。
  3. 反応: 他のストアや機能がリッスンし、反応します。

📦 3. プロジェクト構造と命名

レイヤー タイプ パターン
ドメイン エンティティ {name}.entity.ts
アプリケーション ストア {name}.store.ts
インフラストラクチャ リポジトリ {name}-firestore.repository.ts
プレゼンテーション コンポーネント {name}.component.ts
  • エイリアスインポート: @domain/*、@application/*、@infrastructure/* を使用します。
  • 相対インポートの禁止: ../../ を使用してレイヤーをまたいでインポートすることはありません。

🪒 4. オッカムの剃刀

  • ミニマリズム: 必要性なしにレイヤーや抽象化を追加しないでください。
  • 凝集度: 関連するロジックは近くに保ってください。
  • 疎結合: モジュール間の依存関係を最小限に抑えてください。

裁定: レイヤーをまたぐインポートやドメイン内の無効なフィールドアクセスに関する TypeScript エラー（TS2339, TS2345）は、アーキテクチャ上の違反です。エラーを抑制するのではなく、設計を修正してください。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

SKILL: Architecture & DDD Master Guide

This document defines the Domain-Driven Design (DDD) architecture and strict layer boundaries for the project.

🏛️ 1. Layered Architecture (The Law)

Dependencies must flow inward: Presentation → Application → Domain ← Infrastructure.

🔴 Domain Layer (src/app/domain/)

  • Purity: Zero framework dependencies (No Angular, No Firebase, No RxJS).
  • Entities: Minimal, intention-free models.
  • Value Objects: Immutable, validated at creation.
  • Repositories: Interfaces ONLY (ports).
  • Aggregates: Transactional boundaries.
  • Domain Events: Immutable "facts" that have occurred.

🟡 Application Layer (src/app/application/)

  • Orchestration: Implements Use Cases (Handlers).
  • State: NgRx Signals (Store) is the source of truth.
  • Mappers: Domain ↔ DTO / ViewModel conversion.
  • Ports: Defines repository and service interfaces.

🔵 Infrastructure Layer (src/app/infrastructure/)

  • Adapters: Implements interfaces defined in the application/domain layers.
  • Technical: Firebase, HTTP, persistence, logging, external SDKs.
  • DTOs: Confined to this layer; never leaked to Presentation or Domain.

🟢 Presentation Layer (src/app/presentation/)

  • UI Only: No business logic.
  • Signals: Consumes signals from stores.
  • Standalone: All components are standalone + zone-less.

🧩 2. Tactical DDD Patterns

Repository Pattern

  • Interface defined in Domain or Application.
  • Implementation hidden in Infrastructure.
  • Injection via InjectionToken to ensure loose coupling.

Domain Service

  • Used when logic involves multiple entities or doesn't naturally fit into one.
  • Must remain pure (no I/O).

Event-Driven Flow

  1. Append: Persist a command outcome to the store/database.
  2. Publish: Emit event via the EventBus.
  3. React: Other stores or capabilities listen and react.

📦 3. Project Structure & Naming

Layer Type Pattern
Domain Entity {name}.entity.ts
Application Store {name}.store.ts
Infrastructure Repository {name}-firestore.repository.ts
Presentation Component {name}.component.ts
  • Alias Imports: Use @domain/*, @application/*, @infrastructure/*.
  • No Relative Imports: Never import across layers using ../../.

🪒 4. Occam's Razor

  • Minimalism: Do not add layers or abstractions without necessity.
  • Cohesion: Keep related logic close.
  • Decoupling: Minimize dependencies between modules.

Adjudication: TypeScript errors (TS2339, TS2345) regarding cross-layer imports or invalid field access in the Domain are architectural violations—fix the design, do not suppress the error.