architecture-consultation

name	architecture-consultation
description	新機能や変更の設計判断について相談する際に使用する。どの層に配置すべきか、インターフェースの分割、既存サービスの拡張か新規作成かなどの判断を支援する。

設計相談

このプロジェクトの設計判断を支援する。新機能や変更がクリーンアーキテクチャの原則に沿っているかを検証する際に参照する。

どの層に配置するか

• ビジネスルール(データの判定、変換、検証): domain/entity
• インターフェース定義: domain/repository
• ユースケース(複数リポジトリの協調、処理フロー): application
• 外部サービスとの通信: infrastructure
• 設定値の読み込みと変換: interfaces/config

新しいインターフェースを定義すべきか

以下のすべてに該当する場合、domain/repositoryに新しいインターフェースを定義する。

• application層から外部リソースへのアクセスが必要
• テスト時にモックへの差し替えが必要
• 実装の詳細をdomain層から隠蔽したい

インターフェースは小さく保つ。1つのインターフェースに含めるメソッドは必要最小限にする。

既存のサービスを拡張するか、新しいサービスを作るか

RSSFeedServiceに追加すべき場合:

• RSSフィードの取得から投稿までのフローに影響する機能
• 既存のリポジトリと協調して動作する機能

別のサービスとして分離すべき場合:

• RSSフィード処理と無関係な独立した機能
• 異なるライフサイクルで実行される機能

現在のデータフロー

1. main.goが設定を読み込み、すべての依存を組み立てる
2. RSSFeedServiceがタイマーで定期的にProcessAllFeedsを呼び出す
3. 各RSSURLについてフィードを取得し、キャッシュで未処理エントリを判定する
4. 未処理エントリについてLLMで要約を生成する(有効な場合)
5. Noteエンティティを構築し、レートリミッタ付きでMisskey APIに投稿する
6. 処理済みGUIDをキャッシュに記録する

設定の追加方法

1. interfaces/config/config.goのConfig構造体にフィールドを追加する
2. envconfigタグで環境変数名とデフォルト値を指定する
3. 必要に応じてゲッターメソッドで型変換する(秒をtime.Durationへ変換するなど)
4. main.goで設定値を読み取り、対応するインフラ層の構造体に渡す

並行処理の設計判断

• レートリミッタはinfrastructure層で実装する
• 共有状態へのアクセスはsync.Mutexで保護する
• context.Contextをすべての非同期処理に伝播する
• ゴルーチンを起動する場合はシグナル受信時の終了処理を明確にする