設計相談
このプロジェクトの設計判断を支援する。新機能や変更がクリーンアーキテクチャの原則に沿っているかを検証する際に参照する。
どの層に配置するか
- •ビジネスルール(データの判定、変換、検証): 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をすべての非同期処理に伝播する
- •ゴルーチンを起動する場合はシグナル受信時の終了処理を明確にする