| name | architecture-consultation |
| description | 新機能や変更の設計判断について相談する際に使用する。どの層に配置すべきか、インターフェースの分割、既存サービスの拡張か新規作成かなどの判断を支援する。 |
設計相談
このプロジェクトの設計判断を支援する。新機能や変更がクリーンアーキテクチャの原則に沿っているかを検証する際に参照する。
どの層に配置するか
- ビジネスルール(データの判定、変換、検証): domain/entity
- インターフェース定義: domain/repository
- ユースケース(複数リポジトリの協調、処理フロー): application
- 外部サービスとの通信: infrastructure
- 設定値の読み込みと変換: interfaces/config
新しいインターフェースを定義すべきか
以下のすべてに該当する場合、domain/repositoryに新しいインターフェースを定義する。
- application層から外部リソースへのアクセスが必要
- テスト時にモックへの差し替えが必要
- 実装の詳細をdomain層から隠蔽したい
インターフェースは小さく保つ。1つのインターフェースに含めるメソッドは必要最小限にする。
既存のサービスを拡張するか、新しいサービスを作るか
RSSFeedServiceに追加すべき場合:
- RSSフィードの取得から投稿までのフローに影響する機能
- 既存のリポジトリと協調して動作する機能
別のサービスとして分離すべき場合:
- RSSフィード処理と無関係な独立した機能
- 異なるライフサイクルで実行される機能
現在のデータフロー
- main.goが設定を読み込み、すべての依存を組み立てる
- RSSFeedServiceがタイマーで定期的にProcessAllFeedsを呼び出す
- 各RSSURLについてフィードを取得し、キャッシュで未処理エントリを判定する
- 未処理エントリについてLLMで要約を生成する(有効な場合)
- Noteエンティティを構築し、レートリミッタ付きでMisskey APIに投稿する
- 処理済みGUIDをキャッシュに記録する
設定の追加方法
- interfaces/config/config.goのConfig構造体にフィールドを追加する
- envconfigタグで環境変数名とデフォルト値を指定する
- 必要に応じてゲッターメソッドで型変換する(秒をtime.Durationへ変換するなど)
- main.goで設定値を読み取り、対応するインフラ層の構造体に渡す
並行処理の設計判断
- レートリミッタはinfrastructure層で実装する
- 共有状態へのアクセスはsync.Mutexで保護する
- context.Contextをすべての非同期処理に伝播する
- ゴルーチンを起動する場合はシグナル受信時の終了処理を明確にする
