mcpField
C
creating-springboot-projects

creating-springboot-projects

github.com/a-pavithraa開発8062 回インストール今日更新
リポジトリ

creating-springboot-projects について

creating-springboot-projectsは、新しいSpring Boot 4プロジェクトの計画とひな形作成を支援するスキルです。プロジェクトの要件に応じたアーキテクチャと基本依存関係を選び、同梱テンプレートを適用します。

主な機能

  1. 01複雑さと制約の評価
  2. 025種類のアーキテクチャパターン選択
  3. 03Spring Boot 4の構成と依存関係の選定
  4. 04同梱プロジェクトテンプレートの適用
  5. 05アーキテクチャと機能の資料参照

活用シーン

  1. 01新しいSpring Boot 4サービスの計画
  2. 02成長するアプリケーションの構成選択
  3. 03再利用可能なテンプレートでのモジュール作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/a-pavithraa/springboot-skills-marketplace --skill creating-springboot-projects

インストール後、Claude Code で/creating-springboot-projectsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
api-versioning-config.java
base-entity.java
controller.java
docker-compose.yml
exception-handler.java
flyway-migration.sql
http-service-client.java
modularity-test.java
package-info-jspecify.java
pom-additions.xml
repository.java
resilience-service.java
resttestclient-test.java
rich-entity.java
service-cqrs.java
spring-converter.java
testcontainers-test.java
value-object.java
references/
architecture-guide.md
spring-boot-4-features.md

詳細

Spring Boot プロジェクトの作成

目的

このスキルを使うと、新しい Spring Boot 4 プロジェクトを作成したり、実装前にその構成を定義したりできます。アーキテクチャの決定、Spring Boot 4 の機能選定、または assets/ に含まれるテンプレートが必要な場合に役立ちます。

重要なルール

  • プロジェクトの複雑さを評価する前に、実装に着手してはいけません。
  • ドメインに適した、最もシンプルなアーキテクチャを標準とします。
  • Spring Boot 4 を対象とします。新規プロジェクトでは Java 25（現行 LTS）を標準とします。Boot 4 の公式な最小要件は Java 17 です。ユーザーが希望する場合は、Java 21（前世代の LTS）または Java 17 を使用できます。Java 26 は最新の機能リリース（GA 2026-03-17）ですが、非 LTS です。非 LTS の Java を採用するプロジェクトでのみ選択してください。
  • より複雑なアーキテクチャやオプションのフレームワーク機能を選ぶ前に、リファレンスファイルを読んでください。
  • 同じ足場を一から作り直すのではなく、assets/ のテンプレートを再利用してください。

ワークフロー

ステップ 1：プロジェクトの概要を評価する

まず、プロジェクトの制約を確認します。

  1. ドメインの複雑さ：単純な CRUD、中程度のワークフロー、または豊富なドメインルール。
  2. チームの規模：1～3 人、3～10 人、または 10 人以上。
  3. 想定される存続期間：数か月、1～2 年、または 5 年以上。
  4. 型安全性のニーズ：基本的なバリデーション、または値オブジェクトを多用する厳格なモデリング。
  5. 境界づけられたコンテキスト：単一のドメイン、または複数の機能領域。
  6. 永続化とインフラストラクチャのニーズ：データベースの選択、マイグレーションツール、ローカル開発環境のセットアップ。
ステップ 2：アーキテクチャを選択する

以下の表を、標準的な判断材料として使用します。選択が明確でない場合は、先に references/architecture-guide.md を読んでください。

パターン使用する場合複雑さ
layeredCRUD サービス、プロトタイプ、MVP低
package-by-module中程度の成長が見込まれる、3～5 個の明確な機能低～中
modular-monolithモジュール境界が重要で、Spring Modulith を導入する正当性がある場合中
tomato豊富なドメインモデリング、値オブジェクト、より厳格な型安全性中～高
ddd-hexagonal複雑なドメイン、CQRS、強力なインフラストラクチャ分離高

tomato は値オブジェクトを多用するモジュラーモノリスです。JPA エンティティに VO を埋め込み、バリデーションを VO のコンストラクターに配置し、リクエスト境界で Spring コンバーターを使って VO をバインドします。全容については references/architecture-guide.md を参照してください。

ステップ 3：初期の Boot 4 セットアップを定義する

Spring Initializr を使い、基本設定を記録します。

  • プロジェクト：Maven または Gradle
  • 言語：Java
  • Spring Boot：4.1.x
  • Java：25（推奨 — 現行 LTS）。Boot 4 の最小要件は Java 17 です。前世代の LTS には 21、より厳格な互換性が必要な場合は 17 を使用してください。Java 26（GA 2026-03-17）は最新の機能リリースですが、非 LTS です。

ほとんどのプロジェクトでの基本的な依存関係：

  • Spring Web MVC
  • Validation
  • 永続化が必要な場合は Spring Data JPA
  • Flyway または Liquibase
  • データベースドライバー
  • Spring Boot Actuator
  • 統合テスト用の Testcontainers

アーキテクチャや機能に応じたオプションの依存関係：

  • モジュラーモノリスまたは tomato の設計には Spring Modulith
  • より厳格なアーキテクチャの適用には ArchUnit
  • 用途上必要な場合に限り、Spring Boot 4 の追加機能

以下を選択する前に、references/spring-boot-4-features.md を読んでください。

  • RestTestClient
  • HTTP Service Clients
  • API バージョニング
  • JSpecify の null 安全性
  • 回復性機能
ステップ 4：該当するアセットを適用する

assets/ に含まれるテンプレートを使用し、パッケージ名とモジュール名が決まってからプレースホルダーを置き換えてください。

プレースホルダーの規則

すべてのテンプレートでは、{{TOKEN}} プレースホルダーを使用します。適用する前に、すべてのプレースホルダーを置き換えてください。プレースホルダーがすべて置き換えられるまで、テンプレートはコンパイルできません。assets/ 全体で使用されているプレースホルダーは次のとおりです。

プレースホルダー置き換える値例
{{PACKAGE}}ベースとなる Java パッケージcom.acme.shop
{{MODULE}}機能／モジュール名（小文字）orders
{{NAME}}ドメイン型名（パスカルケース）Order、ProductSKU
{{TYPE}}値オブジェクト内でラップするスカラー型String、Long、BigDecimal
{{FIELD}}レコードのフィールド名（キャメルケース）code、amount
{{TABLE_NAME}}データベースのテーブル名（JPA の @Table で使用）orders
{{TABLE}}{{TABLE_NAME}} と同じ意味です。flyway-migration.sql だけで使われているレガシー形式です。orders
{{PROJECT_NAME}}プロジェクトの artifactId／Docker プレフィックス（docker-compose.yml だけで使用）shop-api
{{name}}HTTP サービスのグループ識別子です。{{NAME}} を小文字にした形式ではありません。コメントアウトされた @ImportHttpServices(group = "...") の例にのみ登場します。orders

ここに記載されていないプレースホルダーがテンプレートに含まれている場合は、誤記として扱い、適用する前に意図する値を確認してください。

コアプロジェクトのテンプレート：

  • assets/controller.java
  • assets/repository.java
  • assets/base-entity.java
  • assets/rich-entity.java
  • assets/value-object.java
  • assets/spring-converter.java
  • assets/service-cqrs.java
  • assets/exception-handler.java
  • assets/flyway-migration.sql
  • assets/docker-compose.yml

Boot 4 とモジュール化のテンプレート：

  • assets/http-service-client.java
  • assets/api-versioning-config.java
  • assets/resttestclient-test.java
  • assets/package-info-jspecify.java
  • assets/modularity-test.java
  • assets/resilience-service.java
  • assets/pom-additions.xml
  • assets/testcontainers-test.java
Step 5: アーキテクチャ固有の要素を補う

パッケージ構造を確認するため、references/architecture-guide.md を読み、該当するテンプレートを適用してください。

  • layered：モジュールをシンプルに保ち、時期尚早な DDD 抽象化を避けます
  • package-by-module：機能ごとにまとめ、共有コードを最小限に抑えます
  • modular-monolith：Modulith による検証と、明示的なモジュール API を追加します
  • tomato：重要な不変条件を保護する場合は、値オブジェクトとリッチドメインエンティティを追加します
  • ddd-hexagonal：アプリケーション、ドメイン、インフラストラクチャを明確に分離します
Step 6: 必要に応じて専門的な課題を引き継ぐ
  • より詳細なクエリ、プロジェクション、リポジトリ、または関連の設計が必要な場合は、spring-data-jpa を使用してください。
  • 新規プロジェクトのセットアップではなく、既存アプリケーションのアップグレードには springboot-migration を使用してください。

リファレンスの読み込みガイド

  • パッケージ構造、アンチパターン、アップグレードパス：references/architecture-guide.md
  • Spring Boot 4 の機能固有のガイダンス：references/spring-boot-4-features.md

出力形式

ユーザーから計画またはスキャフォールドの推奨を求められた場合は、次を返してください。

## Recommended architecture
- Pattern:
- Why:

## Initial setup
- Build tool:
- Java version:
- Spring Boot version:
- Core dependencies:

## Assets to apply
- `assets/...`

## Next implementation steps
1. ...
2. ...
3. ...

このスキルを使用しない場合

  • 既存の Boot プロジェクトを移行する場合
  • プロジェクト作成全般に関する作業を伴わない、リポジトリやクエリの詳細なチューニング
  • 同梱テンプレートが不要な、一般的な Spring Boot 機能に関する質疑応答

コメント

Markdown 対応