Menu
設計ドキュメントに基づいて実装計画を生成します。ScalarDB特有のスキーマ定義、トランザクション実装、統合テストを含む実装可能なタスク指示書を作成し、フェーズ別の実装ロードマップを提供します。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | implementation-plan |
| description | 設計ドキュメントに基づいて実装計画を生成します。ScalarDB特有のスキーマ定義、トランザクション実装、統合テストを含む実装可能なタスク指示書を作成し、フェーズ別の実装ロードマップを提供します。 |
設計ドキュメントを実装可能なタスクに分解し、以下を生成します：
タスク指示書の作成にあたっては、以下の資料を参照してください：
| 資料 | パス | 参照内容 |
|---|---|---|
| Phase 1 設計書 | output/phase1/ | 要求分析、ユースケース |
| Phase 2 設計書 | output/phase2/ | ドメインモデル、境界づけられたコンテキスト |
| Phase 3 設計書 | output/phase3/ | モジュール設計、API設計 |
| 実装ガイド | workflow/11_implementation_guide.md | 実装手順、ScalarDB実装パターン |
| パラメータ | 必須 | 説明 | デフォルト |
|---|---|---|---|
| projectName | Yes | プロジェクト名 | - |
| designDocs | Yes | 設計ドキュメントパス | output/ |
| targetLanguage | No | 実装言語 | java |
| framework | No | フレームワーク | spring-boot |
| testFramework | No | テストフレームワーク | junit5 |
| scalarDBVersion | No | ScalarDBバージョン | 3.x |
flowchart TD
DM[ドメインモデル] --> E[エンティティ実装タスク]
DM --> VO[値オブジェクト実装タスク]
DM --> DS[ドメインサービス実装タスク]
DM --> R[リポジトリ実装タスク]
MS[モジュール設計] --> PKG[パッケージ作成タスク]
MS --> CFG[設定クラス実装タスク]
MS --> API[API実装タスク]
SDB[ScalarDB設計] --> SCHEMA[スキーマ定義タスク]
SDB --> TX[トランザクション実装タスク]
SDB --> COORD[Coordinator設定タスク]
E --> TEST[テスト実装タスク]
VO --> TEST
DS --> TEST
API --> TEST
TX --> SDBTEST[ScalarDB統合テスト]
| カテゴリ | 説明 | 優先度 |
|---|---|---|
| foundation | 基盤構築（プロジェクト構成、共通ライブラリ） | Phase 1 |
| domain | ドメイン層実装（エンティティ、値オブジェクト） | Phase 1 |
| scalardb-schema | ScalarDBスキーマ定義（テーブル、Coordinator） | Phase 2 |
| infrastructure | インフラ層実装（リポジトリ、ScalarDB連携） | Phase 2 |
| scalardb-transaction | ScalarDBトランザクション実装（2PC、OCC） | Phase 2 |
| application | アプリケーション層実装（ユースケース） | Phase 3 |
| presentation | プレゼンテーション層実装（API、DTO） | Phase 3 |
| scalardb-integration | ScalarDB統合テスト（障害シナリオ、競合） | Phase 3 |
目標: プロジェクト基盤とドメイン層の構築
## Phase 1: 基盤構築
### 1.1 プロジェクトセットアップ
- [ ] Gradleプロジェクト作成
- [ ] ScalarDB依存関係設定
- [ ] マルチモジュール構成
### 1.2 共通基盤
- [ ] 共通例外クラス
- [ ] ScalarDB例外ハンドリング基盤
- [ ] ドメインイベント基盤
- [ ] バリデーション基盤
### 1.3 ドメイン層
- [ ] エンティティ実装
- [ ] 値オブジェクト実装
- [ ] リポジトリインターフェース
- [ ] ドメインサービス
### 完了条件
- 全ドメインクラスが実装済み
- 単体テストカバレッジ80%以上
目標: ScalarDBスキーマ定義とインフラ層の構築
## Phase 2: ScalarDB・インフラ実装
### 2.1 ScalarDBスキーマセットアップ
- [ ] ScalarDBスキーマ定義（JSON）
- [ ] テーブル作成スクリプト
- [ ] Coordinator設定
- [ ] トランザクションマネージャ設定
### 2.2 インフラストラクチャ層
- [ ] ScalarDB Repository実装
- [ ] トランザクション境界実装
- [ ] エラーハンドリング・リトライロジック
- [ ] データマッピング
### 2.3 ScalarDBトランザクション実装
- [ ] 2PC（Two-Phase Commit）実装
- [ ] OCC（Optimistic Concurrency Control）実装
- [ ] トランザクション分離レベル設定
- [ ] デッドロック対策
### 2.4 アプリケーション層
- [ ] UseCase実装
- [ ] ApplicationService実装
- [ ] DTOマッピング
### 完了条件
- 全スキーマが定義済み
- 全ユースケースが実装済み
- ScalarDBトランザクションテストパス
目標: API公開とScalarDB統合テスト
## Phase 3: API・統合テスト
### 3.1 プレゼンテーション層
- [ ] Controller実装
- [ ] Request/Response DTO
- [ ] バリデーション
- [ ] エラーハンドリング
### 3.2 ScalarDB統合テスト
- [ ] 2PC障害シナリオテスト
- [ ] Prepare失敗時のロールバック
- [ ] Commit失敗時のリカバリ
- [ ] Coordinatorダウン時の挙動
- [ ] OCC競合テスト
- [ ] 楽観的ロック競合検証
- [ ] リトライロジック検証
- [ ] パフォーマンステスト
- [ ] 高負荷時のトランザクション性能
- [ ] コネクションプール設定検証
### 3.3 E2Eテスト
- [ ] API結合テスト
- [ ] 複数トランザクション連携テスト
- [ ] エラーケーステスト
### 3.4 ドキュメント
- [ ] API仕様書生成
- [ ] ScalarDB設定ガイド
- [ ] README更新
### 完了条件
- 全APIエンドポイント公開
- 全障害シナリオテストパス
- ドキュメント完成
各タスクは output/phase4/tasks/{task-id}.md として出力：
# タスク: {task-id}
## 基本情報
| 項目 | 内容 |
|------|------|
| タスクID | {task-id} |
| カテゴリ | {category} |
| フェーズ | {phase} |
| 優先度 | {priority} |
| 依存タスク | {dependencies} |
## 概要
{task_description}
## 実装内容
### 対象ファイル
| ファイル | 操作 | 説明 |
|---------|------|------|
| {file_path} | 新規作成/修正 | {description} |
### 実装仕様
{implementation_spec}
### コード例
```{language}
{code_example}
| テストケース | 説明 | 期待結果 |
|---|---|---|
| {test_case} | {description} | {expected} |
{test_code_example}
#### 4.2 タスク種別ごとのテンプレート
**エンティティ実装タスク**:
```markdown
## 実装内容
### エンティティ: {EntityName}
**パッケージ**: `{package}.domain.{context}.model`
**属性**:
| 属性 | 型 | 説明 | 制約 |
|------|-----|------|------|
| {attr} | {type} | {desc} | {constraints} |
**メソッド**:
| メソッド | 説明 |
|---------|------|
| {method} | {description} |
### コード例
```java
package {package}.domain.{context}.model;
import lombok.Getter;
import lombok.EqualsAndHashCode;
@Getter
@EqualsAndHashCode(of = "id")
public class {EntityName} {
private final {EntityName}Id id;
// ... 属性
private {EntityName}({EntityName}Id id, ...) {
// バリデーション
this.id = id;
}
public static {EntityName} create(...) {
return new {EntityName}(...);
}
// ビジネスメソッド
}
**ScalarDBスキーマ定義タスク**:
```markdown
## 実装内容
### テーブル: {table_name}
**名前空間**: `{namespace}`
**テーブル定義**:
| カラム | 型 | パーティションキー | クラスタリングキー | セカンダリインデックス |
|--------|-----|-------------------|-------------------|---------------------|
| {column} | {type} | {partition} | {clustering} | {index} |
### スキーマファイル例
```json
{
"{namespace}.{table_name}": {
"transaction": true,
"partition-key": ["{partition_key}"],
"clustering-key": ["{clustering_key}"],
"columns": {
"{column_name}": "{type}",
"tx_id": "TEXT",
"tx_state": "INT",
"tx_version": "INT",
"tx_prepared_at": "BIGINT",
"tx_committed_at": "BIGINT",
"before_{column}": "{type}"
}
}
}
{
"coordinator.namespace": "{coordinator_namespace}",
"coordinator.table": "coordinator"
}
**ScalarDBトランザクション実装タスク**:
```markdown
## 実装内容
### トランザクション: {transaction_name}
**タイプ**: {2PC/OCC}
**対象テーブル**:
| テーブル | 操作 |
|---------|------|
| {table} | {READ/WRITE/DELETE} |
### 実装パターン
```java
package {package}.infrastructure.scalardb;
import com.scalar.db.api.DistributedTransaction;
import com.scalar.db.api.DistributedTransactionManager;
import com.scalar.db.exception.*;
@Repository
@RequiredArgsConstructor
public class {Entity}ScalarDbRepository implements {Entity}Repository {
private final DistributedTransactionManager manager;
@Override
public {Entity} save({Entity} entity) {
DistributedTransaction tx = null;
try {
tx = manager.start();
// PUT操作
Put put = Put.newBuilder()
.namespace("{namespace}")
.table("{table}")
.partitionKey(Key.ofText("{key}", entity.getId().value()))
// カラム設定
.build();
tx.put(put);
tx.commit();
return entity;
} catch (CrudConflictException e) {
// OCC競合時のリトライ処理
if (tx != null) {
tx.rollback();
}
throw new OptimisticLockException("OCC conflict detected", e);
} catch (CommitException e) {
// Commit失敗時のハンドリング
if (tx != null) {
tx.rollback();
}
throw new TransactionCommitException("Commit failed", e);
} catch (Exception e) {
// その他の例外
if (tx != null) {
tx.rollback();
}
throw new RepositoryException("Transaction failed", e);
}
}
}
| 例外 | 原因 | 対応 |
|---|---|---|
| CrudConflictException | OCC競合 | リトライ（最大3回） |
| CommitException | Commit失敗 | ロールバック後エラー通知 |
| UnknownTransactionStatusException | トランザクション状態不明 | 手動確認が必要 |
統合テスト:
| テストケース | 説明 | 期待結果 |
|---|---|---|
| 正常系 | トランザクション成功 | データが永続化される |
| OCC競合 | 同時更新による競合 | リトライ後成功 or 失敗例外 |
| Prepare失敗 | Prepare phase失敗 | ロールバック実行 |
| Commit失敗 | Commit phase失敗 | エラー通知、手動リカバリ |
**ScalarDB統合テストタスク**:
```markdown
## 実装内容
### テストケース: {test_name}
**テストタイプ**: 2PC障害シナリオ / OCC競合
**テスト対象**:
| コンポーネント | 説明 |
|---------------|------|
| {component} | {description} |
### テストコード例
```java
package {package}.infrastructure.scalardb;
import com.scalar.db.api.DistributedTransactionManager;
import com.scalar.db.exception.transaction.*;
import org.junit.jupiter.api.*;
import org.testcontainers.containers.CassandraContainer;
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class {Entity}ScalarDbRepositoryIntegrationTest {
private static CassandraContainer<?> cassandra;
private DistributedTransactionManager manager;
private {Entity}ScalarDbRepository repository;
@BeforeAll
static void setUpContainer() {
cassandra = new CassandraContainer<>("cassandra:4.1")
.withExposedPorts(9042);
cassandra.start();
}
@Test
@DisplayName("2PC Prepare失敗時にロールバックが実行される")
void testPrepareFailureRollback() {
// Given: 不正なデータでPrepare失敗を誘発
// When: トランザクション実行
assertThrows(TransactionException.class, () -> {
repository.save(invalidEntity);
});
// Then: ロールバック確認
Optional<{Entity}> result = repository.findById(invalidEntity.getId());
assertThat(result).isEmpty();
}
@Test
@DisplayName("OCC競合時にリトライが実行される")
void testOccConflictRetry() throws Exception {
// Given: 同じエンティティを2つのトランザクションで更新
{Entity} entity = {Entity}.create(...);
repository.save(entity);
// When: 並行更新
CompletableFuture<Void> tx1 = CompletableFuture.runAsync(() -> {
repository.update(entity.updateField1());
});
CompletableFuture<Void> tx2 = CompletableFuture.runAsync(() -> {
repository.update(entity.updateField2());
});
// Then: 片方は成功、片方はリトライ後に成功 or 失敗
CompletableFuture.allOf(tx1, tx2).join();
// 最終的にどちらかの更新が反映されている
Optional<{Entity}> result = repository.findById(entity.getId());
assertThat(result).isPresent();
}
@Test
@DisplayName("Coordinatorダウン時の挙動検証")
void testCoordinatorDown() {
// Given: Coordinator停止
stopCoordinator();
// When: トランザクション実行
assertThrows(TransactionException.class, () -> {
repository.save(entity);
});
// Then: エラーが適切にハンドリングされる
}
@AfterAll
static void tearDown() {
cassandra.stop();
}
}
2PC障害シナリオ:
OCC競合シナリオ:
**API実装タスク**:
```markdown
## 実装内容
### エンドポイント
| メソッド | パス | 説明 |
|---------|------|------|
| {method} | {path} | {description} |
### Request/Response
**Request**:
```json
{request_example}
Response:
{response_example}
@RestController
@RequestMapping("/api/v1/{resources}")
@RequiredArgsConstructor
public class {Entity}Controller {
private final {Entity}UseCase {entity}UseCase;
@PostMapping
public ResponseEntity<{Entity}Response> create(
@Valid @RequestBody Create{Entity}Request request) {
var result = {entity}UseCase.execute(request.toCommand());
return ResponseEntity.status(HttpStatus.CREATED)
.body({Entity}Response.from(result));
}
}
---
### Stage 5: 依存関係の解決
#### 5.1 タスク依存グラフ
```mermaid
graph TD
T001[プロジェクトセットアップ] --> T002[共通基盤]
T002 --> T003[エンティティ実装]
T002 --> T004[値オブジェクト実装]
T003 --> T005[リポジトリIF]
T004 --> T003
T002 --> T006[ScalarDBスキーマ定義]
T006 --> T007[Coordinator設定]
T007 --> T008[ScalarDB Repository実装]
T005 --> T008
T008 --> T009[トランザクション実装]
T009 --> T010[エラーハンドリング実装]
T010 --> T011[UseCase実装]
T003 --> T012[ドメインサービス]
T012 --> T011
T011 --> T013[Controller実装]
T009 --> T014[ScalarDB統合テスト]
T013 --> T015[E2Eテスト]
def determine_execution_order(tasks):
# トポロジカルソートで依存関係を解決
sorted_tasks = topological_sort(tasks, dependencies)
# フェーズごとにグループ化
phases = group_by_phase(sorted_tasks)
return phases
output/phase4/11_implementation_guide.md:
# 実装計画書
## 1. 概要
| 項目 | 内容 |
|------|------|
| プロジェクト | {projectName} |
| 言語/FW | {language} / {framework} |
| ScalarDBバージョン | {scalarDBVersion} |
| 総タスク数 | {total_tasks} |
| フェーズ数 | 3 |
## 2. フェーズ別計画
### Phase 1: 基盤構築
| タスクID | タスク名 | 依存 | 状態 |
|---------|---------|------|------|
| {id} | {name} | {deps} | 未着手 |
### Phase 2: ScalarDB・インフラ実装
{phase2_tasks}
### Phase 3: API・統合テスト
{phase3_tasks}
## 3. タスク依存関係
```mermaid
{dependency_graph}
tx_id, tx_state, tx_version などの管理カラムが必要CrudConflictException の適切なハンドリングCommitException: ロールバック必須UnknownTransactionStatusException: 手動確認が必要output/phase4/tasks/T001-*.md から順に実行各タスクファイルを以下のように渡す:
タスク指示書: output/phase4/tasks/T001-project-setup.md
**output/phase4/tasks/*.md**: 個別タスク指示書
---
## 使用例
### 例1: 設計からの実装計画生成
Skill: implementation-plan
### 例2: 特定フェーズのみ
Skill: implementation-plan
### 例3: ScalarDB統合テストのみ
Skill: implementation-plan
## 注意事項
- タスクは依存関係順に実行してください
- ScalarDBスキーマは事前に定義・適用が必要
- トランザクション実装では必ずリトライロジックを含めてください
- 統合テストは全障害シナリオをカバーしてください
- 各タスクの完了条件を満たしてから次に進んでください
- テストは必ず実装してください
## ScalarDB実装のベストプラクティス
1. **スキーマ設計**
- パーティションキーは均等分散を考慮
- クラスタリングキーでソート順を制御
- セカンダリインデックスは慎重に使用
2. **トランザクション実装**
- トランザクション境界を明確に
- リトライは指数バックオフで実装
- タイムアウト設定を適切に
3. **エラーハンドリング**
- 各例外タイプに応じた適切な処理
- ロールバック漏れに注意
- ログ出力で障害調査を支援
4. **テスト**
- 正常系だけでなく障害系も必ずテスト
- Testcontainersで本番に近い環境
- 並行実行テストでOCC競合を検証
5. **パフォーマンス**
- コネクションプールの適切な設定
- バッチ処理の活用
- 不要なトランザクションは避ける
RESTful API の設計を行います。エンドポイント定義、リクエスト/レスポンス仕様、エラーハンドリング、ScalarDBトランザクション例外のマッピングを含みます。
ScalarDBを前提としたデータベース設計を行います。スキーマ設計、トランザクション設計、マルチストレージ構成を対話形式で決定し、スキーマファイルと設計書を生成します。
DDDに基づいたドメインモデルを設計します。戦略的設計（境界コンテキスト、ユビキタス言語）と戦術的設計（エンティティ、値オブジェクト、集約、ドメインサービス、ドメインイベント）を定義し、ヘキサゴナルアーキテクチャとの統合を行います。ScalarDBのトランザクション境界や管理テーブル分類の考慮事項を含みます。中間状態はresearch/に記録されます。
Kubernetes、Kong API Gateway、ScalarDB Cluster v3.17を使用したインフラストラクチャ設計を行います。マニフェストファイルと設定ファイルを生成します。
ScalarDBの制約を考慮したデータモデル設計を行います。Partition Key・Clustering Key・Secondary Index の設計、ホットスポット評価、メタデータオーバーヘッド見積もり、バックエンドDB選定を含みます。ワークフローStep 04（データモデル設計）で使用します。
ScalarDBのトランザクション設計を行います。トランザクション境界定義、パターン選定（単一集約内/2PC/Saga/ハイブリッド）、OCC競合率評価、バッチ処理設計、v3.17最適化適用計画を含みます。ワークフローStep 05（トランザクション設計）で使用します。