Architectパイプライン

出力はreports/03_design/aggregates/aggregate-manifest.json(AGG-ID)です。集約ごとに、ルート・内部エンティティ・値オブジェクト・不変条件(成立/違反の両方を具体例つきで)・コマンド(実行者・一貫性クラス・発行イベント)・ファクトリ・仕様(Specification)・1集約1リポジトリを定義します。

「1コマンド=1集約=1トランザクション」の原則を含む7つの整形式ルールをrules/aggregate-design.mdが定め、tools/lib/aggregate_manifest.pyが検証します。この集約リストは後続のdesign-state-machineのライフサイクル候補になり、design-scalardb/design-data-layer・design-api・design-implementation・generate-test-specs・review-consistency・reportが成果物を読みます。

集約が発行するイベントは、Domain Event Catalog(reports/03_design/domain-event-catalog.json/.md)としても書き出されます。コンテキストマップのPublished Language(公開された言語)そのもので、発行者・購読するコンテキスト・配信契約(保証レベル・冪等性キー・バージョン)を記録します。design-microservicesがサービス分割確定後に購読側を完成させ、design-apiのasyncapi/はこのカタログから生成されます。

出力はreports/03_design/state-machines/state-machine-manifest.jsonです。ライフサイクルを持つ集約ごとに、状態・イベント・遷移((from, event) [guard] → to。実行者・一貫性クラス・冪等性判定つき)を定義し、状態×イベントの全マスをreject/ignore/deferのいずれかで決め切ります(空欄を実行時の判断に委ねません)。

• 集約を生成するイベント(place・open・registerなど)はfrom状態を持たない特別な列として扱われ、そのidempotency判定はAPIの冪等性契約から機械的に決まります。
• 誰と誰が同じ集約に競合するか(オーケストレータ対リカバリワーカー、リクエスト経路対スイーパーなど)を1行ずつ書く「競合テーブル」も作ります。行がない組は「誰も設計していない競合」を意味します。
• tools/lib/state_machine_manifest.py(29項目)が、初期状態が1つだけ・全状態が到達可能・未宣言のデッドエンドがない、といった整形式ルールを検証します。design-scalardb/design-data-layer・design-api・generate-test-specs・review-consistency・reportがこのモデルを読みます。

出力は、稼働中のレガシーシステムから記録したゴールデンマスターテスト(モジュールごとのSeam一覧、コードが実際に出力した値をそのまま使うフィクスチャ、既知の不具合を壊さず固定する@KnownDefect(DEBT-xx)マーカー)とreports/07_test-specs/characterization-test-coverage.mdです。

design-microservicesの移行計画は、各変換ステップにこの特性テストゲートを必須で紐づけるようになりました。既存の振る舞いを壊さずに変換を進めるための安全網です。

出力は、reports/07_test-specs/のGherkinシナリオ(RULE-/EX-に紐づく)に対応するCucumber-JVMのステップ定義とreports/07_test-specs/acceptance-test-coverage.mdです。Fakeを使ったAPI/アプリケーション層のドライバと、固定したClockで実行します。

まだ実装が届いていないシナリオには@wipタグを付け、合否判定からは除外しつつ件数としては記録します。rules/tdd-workflow.mdのATDD外側ループを実行可能にするスキルです。

出力: 認証基盤(OAuth2/OIDC、サービス間mTLS)・認可モデル(RBAC/ABAC。ロール単位だけでなくオブジェクト単位の認可も含む)・テナント分離モデル・シークレット管理(Vault/KMS、ローテーション戦略)・ネットワークセキュリティ(ゼロトラスト、セグメンテーション)・データ分類(どの項目が機密で、APIレスポンス/ログ/エラー詳細に出してよいか)・監査ログ・コンプライアンスチェックリスト。OWASP API Security Top 10への対応も見ます。

出力: SLI/SLO定義(サービス単位、ビジネスKPIと紐づけ)・分散トレーシング(OpenTelemetry。複数サービスをまたぐ処理をcorrelation IDで追跡)・ログ集約・メトリクス(RED/USE方式)・アラート設計・ScalarDB固有のメトリクス(トランザクション成功率、OCC競合率)。ScalarDB Sagaを使う場合は、サガの状態別件数や補償失敗率も追加します。

出力: サービス階層別のRTO/RPO(復旧までの目標時間・失ってよいデータ量)・バックアップ戦略(頻度・保持期間・復元テスト計画)・フェイルオーバー設計(リージョン間・AZ間)・データ復旧手順(ScalarDBのCoordinatorテーブルを含む)・障害シナリオ別のランブック・カオスエンジニアリング(意図的に障害を起こして耐性を確認する手法)を含む復旧テスト計画。

出力: クラウド基盤費用(AWS/Azure/GCPのコンピュート・ストレージ・ネットワーク)・ScalarDBライセンス費用(エディション別、直接契約かAWS Marketplace経由か)・運用費用(監視ツール・サポート・人件費)・ScalarDBのサイジング(Pod数・クラスタ構成・DB容量)を多面的に見積もります。

出力: Kubernetesクラスタ構成(ノードプール・リソースクォータ・namespace戦略)・コンテナオーケストレーション(デプロイ戦略・HPA・PDB)・ネットワーク設計(mTLS・NetworkPolicy・Ingress/Gateway)・IaC構成(Terraformモジュール・state管理)・複数環境戦略(dev/staging/prod、Kustomizeオーバーレイ)。ScalarDB Cluster使用時はHelmチャート構成とCoordinatorの配置も設計します。

出力はあくまで論理設計で、infraプラグインの/infra:designが同じ領域をマルチクラウド前提の具体設計に落とし込みます(下のPanelを参照)。

3つの視点(構造の一貫性35%・トレーサビリティ35%・用語の一貫性30%)を5点満点で評価します。孤立したセクション、要件→設計→実装のトレースが辿れない箇所、同じ概念に別名がついている箇所などをJSON形式のfindingsとして出力します。

4つの視点(監視・可観測性30%・災害対策30%・セキュリティ姿勢20%・デプロイの安全性20%)で運用面の準備状況を評価します。

4つの視点(分散システムのリスク30%・故障モード分析30%・Saga設計の妥当性25%・データ整合性リスク15%)を、あえて敵対的な立場から評価します。設計者自身が気づきにくいリスクを見つけることが目的で、6視点の中で最も深く掘ります。

4つの視点(要件トレーサビリティ35%・NFRの数値化30%・ステークホルダーとの整合20%・ROI/実現可能性15%)で、ビジネス要件から見た設計の妥当性を評価します。

ScalarDBを使うプロジェクト専用です。3つの視点(サービス間トランザクションの仕組み40%・OCC競合分析35%・スキーマ/API互換性25%)で評価します。

ScalarDBを使わないプロジェクト専用です。3つの視点(トランザクション安全性40%・データ整合性35%・スキーマ設計品質25%)で評価します。review-scalardbとは互いに排他で、どちらか一方だけが実行されます。

2〜6視点の結果を受け取り、次の順で統合します。

どの移行元データベース(Oracle/MySQL/PostgreSQL)かを1つ選んでもらい、対応する専用スキルに振り分けます。実際のスキーマ抽出や変換は行いません。

6つのサブエージェント(3段階の逐次実行 → 3つの並列実行)でスキーマ抽出からJavaコード生成までを行います。

migrate-oracleと同じ考え方(逐次抽出→並列分析・変換)で、スキーマ抽出・移行分析・ストアドプロシージャ/トリガのJava変換を行います。Advanced Queuing連携はOracle固有の機能のため対象外です。

migrate-oracleと同じ考え方で、スキーマ抽出・移行分析・ストアドプロシージャ/トリガのJava変換を行います。Advanced Queuing連携はOracle固有の機能のため対象外です。