Skip to content
cccskills
FreePublished on GitHub

first-class-collection

ファーストクラスコレクションパターンの設計・実装を支援。コレクションをラップする専用クラスの 設計、ドメインロジックの集約、不変性の確保をガイド。コードレビュー、新規実装、リファクタリング 時にコレクション操作ロジックが散在している場合に使用。

対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。

トリガー:「コレクションをラップしたい」「リストのロジックを集約」「ファーストクラスコレクション」 「コレクション操作が散在」「List<Order>をOrdersクラスに」といったコレクション設計関連リクエストで起動。

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md7.9 KB
  • references/patterns.md9.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

First Class Collection

コレクションをラップする専用クラスを作成し、ドメインロジックを集約する。

核心原則

コレクションをラップするクラスは、コレクション以外のフィールドを持たない。 (ThoughtWorks Anthology, Object Calisthenics Rule 4)

アプローチ特徴問題
生のコレクションList<Order> ordersロジック散在、ドメイン概念の欠如
ファーストクラスOrders orders責任集約、ドメイン表現、不変性保証

判断フロー

コレクション型のフィールド/変数
    ↓
ビジネスロジック(集計/フィルタ/バリデーション)が必要か?
    ├─ YES → ファーストクラスコレクション化を検討
    │         ├─ 同じ操作が複数箇所にあるか? → 必須
    │         └─ 1箇所のみ → 将来性を考慮して判断
    └─ NO → 生のコレクションで可

アンチパターン検出

以下のパターンを見つけたら変換を検討:

❌ orders.stream().filter(o -> o.getStatus() == PENDING).toList()  // 複数箇所で同じフィルタ
❌ int total = items.stream().mapToInt(Item::getPrice).sum()       // 呼び出し側で集計
❌ if (users.isEmpty()) throw new EmptyUsersException()            // バリデーション散在
❌ for (Order o : orders) { if (o.isOverdue()) ... }               // 外部でループ処理
❌ orders.add(order)                                                // 直接変更可能

変換パターン

以下の説明にはJavaのコレクションを利用しているが、提供される種々の型は可変コレクションであるため、内部のコレクションをそのまま返すことができないので、複製を作るなど工夫が必要になる。しかし、Scalaのように不変コレクションがある場合は、わざわざそのような考慮は不要であるため、不変コレクションがある場合は優先して利用すること。

1. 基本構造

// ❌ 生のコレクション
List<Order> orders;

// ✅ ファーストクラスコレクション
public final class Orders {
    private final List<Order> values;

    public Orders(List<Order> values) {
        this.values = List.copyOf(values);  // 不変性保証
    }

    // ドメインロジックをここに集約
}

2. 集計ロジックの集約

// ❌ 呼び出し側で集計
Money total = Money.ZERO;
for (Order order : orders) {
    total = total.add(order.getAmount());
}

// ✅ コレクションに集約
public Money totalAmount() {
    return values.stream()
        .map(Order::amount)
        .reduce(Money.ZERO, Money::add);
}

3. フィルタリングの内部化

// ❌ 外部でフィルタリング
List<Order> pending = orders.stream()
    .filter(o -> o.getStatus() == PENDING)
    .toList();

// ✅ ドメイン用語でメソッド化
public Orders pending() {
    return new Orders(
        values.stream()
            .filter(Order::isPending)
            .toList()
    );
}

4. バリデーションの集約

// ❌ 外部でバリデーション
if (orders.isEmpty()) {
    throw new IllegalArgumentException("注文がありません");
}

// ✅ 生成時にバリデーション
public Orders(List<Order> values) {
    if (values.isEmpty()) {
        throw new EmptyOrdersException();
    }
    this.values = List.copyOf(values);
}

5. 不変な追加操作

// ❌ 破壊的変更
orders.add(newOrder);

// ✅ 新しいインスタンスを返す
public Orders add(Order order) {
    List<Order> newList = new ArrayList<>(values);
    newList.add(order);
    return new Orders(newList);
}

言語別イディオム

TypeScript

class Orders {
    private constructor(private readonly values: readonly Order[]) {}

    static of(orders: Order[]): Orders {
        return new Orders([...orders]);
    }

    totalAmount(): Money {
        return this.values.reduce(
            (sum, order) => sum.add(order.amount),
            Money.ZERO
        );
    }
}

Rust

pub struct Orders(Vec<Order>);

impl Orders {
    pub fn new(orders: Vec<Order>) -> Self {
        Self(orders)
    }

    pub fn total_amount(&self) -> Money {
        self.0.iter().map(|o| o.amount()).sum()
    }

    pub fn pending(&self) -> Self {
        Self(self.0.iter().filter(|o| o.is_pending()).cloned().collect())
    }
}

Python

@dataclass(frozen=True)
class Orders:
    _values: tuple[Order, ...]

    @classmethod
    def of(cls, orders: list[Order]) -> "Orders":
        return cls(tuple(orders))

    def total_amount(self) -> Money:
        return sum((o.amount for o in self._values), Money.ZERO)

Go

type Orders struct {
    values []Order
}

func NewOrders(orders []Order) Orders {
    copied := make([]Order, len(orders))
    copy(copied, orders)
    return Orders{values: copied}
}

func (o Orders) TotalAmount() Money {
    total := ZeroMoney()
    for _, order := range o.values {
        total = total.Add(order.Amount())
    }
    return total
}

func (o Orders) Pending() Orders {
    var pending []Order
    for _, order := range o.values {
        if order.IsPending() {
            pending = append(pending, order)
        }
    }
    return NewOrders(pending)
}

設計指針

ファーストクラスコレクション化すべきもの

  • ドメインで名前がつくコレクション(「注文一覧」「在庫リスト」等)
  • 集計・フィルタリング・検証ロジックを持つ
  • 複数箇所から同じ操作をされる
  • ビジネスルールに関わる制約がある

生のコレクションで良いもの

  • 純粋なデータ転送(DTO内のリスト)
  • フレームワーク/ライブラリの制約
  • 一時的な中間データ
  • ロジックが不要な単純なグループ化

レビュー観点

  1. ロジック散在: 同じコレクション操作が複数箇所にないか
  2. ドメイン概念: コレクションにビジネス上の名前があるか
  3. 不変性: 外部から直接変更されていないか
  4. 責任: Tell, Don't Askに従っているか

関連原則

原則関係
Tell, Don't Askコレクションに問い合わせず命じる
単一責任原則コレクション操作を一箇所に集約
DRY重複するコレクション操作を排除
カプセル化内部リストを隠蔽

詳細ガイドライン

言語別の詳細パターン、イテレータ実装、テスト方法は references/patterns.md を参照。

関連スキル(併読推奨)

このスキルを使用する際は、以下のスキルも併せて参照すること:

  • tell-dont-ask: コレクションに命じるパターンの基盤原則
  • law-of-demeter: コレクション内部への直接アクセスを防ぐ原則
  • intent-based-dedup: 同じ構造のコレクションでも意図が異なれば共通化しない判断

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること: - 集約(Aggregate)の新規設計・実装・リファクタリング(どの言語でも) - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定(「AとBは同じ集約にすべきか?」「この集約は大きすぎるか?」) - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断(ドメインイベント、結果整合性、Sagaパターン) - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例:集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

See all skills by j5ik2o

Report a problem with this skill