Development Convention

Plugin development-convention from marketplace development-convention in nakamori-naoya/development-convention-plugins. Commands read from the repo's manifest — 1 month ago.

Skills (6)

• apply-layer-convention

  処理ごとの実装パターン（戦術的 DDD か単純なパターンか）、責務の持ち主と依存の向き、command の流れ、不変条件とトランザクションの置き場、Outbox、失敗を閉じ込める基準を、言語に依らずに決めて適用する。「この処理は DDD で書くべきか」「責務の持ち主を決めたい」「複数集約の更新や後続の処理の境界を決めたい」と言われたときに使う。

• apply-yagni

  現在の business-knowledge、domain-model、command-data-model、query-data-model、user-journey-bdd と、それらを写したテストだけを根拠に、対象コードの公開シンボルを keep か reject に分け、要求されない公開面を作らず残さない。「これが本当に必要か」「資料にないコードが混ざっていないか」を判断するときに使う。

• develop-inside-out

  確定済みの資料と、業務の API テストシナリオが決めた公開契約から、一つの場面の受け入れテストを先に赤で置き、ドメイン、永続化または読み取り、usecase、入口の順に、下の層が緑になってから上の層へ進めて一つの機能を完成させる。資料からずらさず推測で埋めない規律、TDD の赤の定義、一つの単位をテスト、赤、実装、緑、整えるの順で進める規律、書く前に書かずに済む道（既存、標準、土台、既存の依存）を探す規律もここが持つ。「資料一式からこの機能を実装して」「次の層へ進めてよいか判定して」と言われたときに使う。

• fix-root-cause

  報告された不具合の症状を、現在の業務の資料が定める期待状態と突き合わせて不具合と確定し、症状を再現するテストを赤で置き、症状を起こす入力が通るすべての呼び出し経路が経由する最も内側の一か所を最小の変更で直してテストを緑にする。「このバグを直して」「この不具合の根本原因を直して」「症状の報告から修正して」と言われたときに使う。要求の追加、資料の補完、症状に関係しない整形や改名、複数の不具合の一括修正は行わない。

• protect-entry-points

  外部から呼べる入口（RPC、HTTP の入口、Server Function、Webhook、ジョブの受信口）を列挙し、入口ごとに認証、認可、利用上限、偽装要求（CSRF）への対策、呼び出す高価な下流の資源を宣言した資料を作る・直す。適用除外にする入口には、下流を何で守るかと、残るリスクを受け入れた決定の所在を書かせる。「入口の保護を宣言して」「この入口にレート制限が要るか決めて」「認証の無い入口を洗い出して」と言われたときに使う。宣言に従ってコードを直すことと、業務の資料を作ることは対象外として返す。

• write-readable-code

  言語に依らず、コードの名前を業務の言葉で付け、コメントを自分の責務だけで業務の言葉で書き、テストのために実装を曲げない、の三つの規律でコードを書く・直す。「この型の名前を決めて」「コメントを直して」「テストしやすいように実装を変えたい」「英名が資料に無い」と言われたとき、また各言語の規約が名前、コメント、テストの規律としてここを指したときに使う。名前の言語ごとの形（接頭辞、大文字小文字）は各言語の規約へ、公開シンボルの要否は apply-yagni へ返す。

Similar plugins