Skill.md検索

ビジネスルールを不変な型で表現: Entity・Value Objectとして、バリデーションを生成時に実施。不正な状態（無効なメールアドレスなど）が作られない「常に正しいドメインモデル」を構築 複数のエンティティにまたがるロジックを整理: Domain Serviceで単一エンティティに属さないドメインロジック（認可判定・状態遷移など）を集約。責務が明確になり、テストがしやすく 外部システムへの依存を抽象化: Port Interfaceで、DB・HTTP・キャッシュなどの外部システムへの依存を宣言。実装の詳細に左右されない安定したドメイン層を実現 他レイヤーに依存しない中核設計: Domain層がUsecase・Infrastructure層から独立。ビジネスロジックの変更が他レイヤーに波及しない エラーをドメイン値として表現: センチネルエラーをportファイルで定義。Infrastructure層から返されるエラーを明示的にキャッチ・処理できる バックエンド開発者: ビジネスロジックを保守性の高い設計に再構成したい アーキテクト: レイヤード・アーキテクチャを正しく実装し、テスト性を確保したい 技術リード: チーム全体でドメイン駆動設計（DDD）の原則を統一したい リファクタリング責任者: レガシーコードをクリーンアーキテクチャに段階的に移行したい Domain層（model/service/port）実装ガイド。Domain層は他レイヤーに依存しないシステム中核。model/（Entity・Value Object）では、非公開フィールド・NewXXXコンストラクタ経由の生成・生成時バリデーション・メソッド経由のアクセスで常に正しい状態を保証。バリデーション必須な場合はerrorを返す、不要ならdefined typeで軽量に。service/（Domain Service）では複数Entity/Value Objectにまたがるロジックや単一エンティティに属さないロジックを実装。ポート（インターフェース）に依存してもよい。port/では外部システム（DB・HTTP・KVS）への依存をインターフェースで抽象化し、戻り値はDomain型のみ使用。Infrastructure層が返すエラーはセンチネルエラーとしてportファイルに定義し、明示的に処理できる仕組み。