- ルートは Cargo ワークスペースで、
applications/が実行可能バイナリを持つ;write-api-serverは GraphQL Mutation、read-api-serverは Query、read-model-updaterはリードモデル更新ロジックを提供する。 - ドメインロジックは
modules/command、読み取り系はmodules/query、更新ワーカはmodules/rmuに集約し、再利用可能なインフラ抽象はmodules/infrastructureで管理する。 - 開発者向け資料は
docs/、運用スクリプトや Docker/E2E 用ユーティリティはtools/に配置される;Lambda 用成果物はdist/lambda/に生成される。環境変数テンプレートはcommon.env.defaultを参照し、編集後はcommon.envを Git 管理から除外したまま保持する。 - モデル固有のテストコードは各
src内のmod testsとして共存させ、共有フィクスチャは必要に応じてmodules配下へ配置する。
- 作業開始時に
cp common.env.default common.envを実行し、接頭辞や AWS 向け設定を更新する。 - RDB 接続が必要な処理の前に
makers docker-compose-up-dbでローカル DB を起動する(makersはcargo makeのラッパー)。 - ビルドは
makers build、フォーマットはmakers fmtまたはcargo +nightly fmtを利用し、GraphQL API はcargo run -p write-api-server --bin write-api-serverなどで個別に起動できる。 - DynamoDB Streams 経由のリードモデル更新を確認したい場合は
makers build-read-model-updater-lambdaで Lambda 用 ZIP を生成し、makers deploy-read-model-updater-localstackで LocalStack にデプロイする。 - テストは
makers testを基準とし、並列数を 1 に固定したRUST_TEST_THREADS=1 cargo testでの再現性を保つ;E2E 確認が必要な場合はmakers verify-group-chatやtools/e2e-test/verify-group-chat.shを使用する。
- Rust コードは 2 スペースインデント・120 文字幅(
rustfmt.toml参照)を厳守し、PR 前に必ずcargo +nightly fmtを実行する。 - モジュール名とファイルは
snake_case、型とトレイトはUpperCamelCase、定数はSCREAMING_SNAKE_CASEを採用する。 - クロスモジュール API にはインターフェイス(trait)を定義し実装を分離する既存パターンに従い、GraphQL 定義は
applications/write-api-server/bin/export-*系バイナリで更新する。 - 新規 SQL を追加した場合は
makers buildを走らせて.sqlx/*.jsonを再生成し、差分をコミットする。
- コンポーネントテストは
testcontainers依存のため Docker を常時起動し、テスト前後にリソースが解放されるか確認する。 - シナリオテストは GraphQL 経由でグループチャットを作成する
makers create-and-get-group-chatを活用し、再現手順を PR 説明に記載する。LocalStack Lambda 検証時はmakers deploy-read-model-updater-localstackの実行結果も記す。 - テストケースは「状態-操作-期待値」を明示した関数名(例:
should_create_group_chat_when_members_valid)とし、serial_testのガードが必要なケースでは既存実装を参照して属性を付与する。 - ログ出力が必要な場合は
RUST_LOG=debugを設定して再実行し、失敗ログを記録する。
- Git 履歴は Conventional Commits に準拠しており、
chore(deps): Update ... (#541)のように種別・スコープ・概要・関連 PR 番号を含める;機能追加はfeat, バグ修正はfixを使用する。 - プルリクエストでは目的、主要変更点、影響範囲、実行済みコマンド(例:
makers test,cargo +nightly fmt)をチェックリスト形式で提示し、関連 Issue や GraphQL リクエスト例をリンクする。 - CI の失敗を未解決のまま提出しないこと、依存ライブラリ更新を含む場合は Renovate 設定との重複を避けること、レビューコメントには 24 時間以内に返信することを推奨する。
- マージ前には最新
mainをリベースし、衝突解消後に再度テストを通す。