Memory Bank MCP Server

{ "schema": "memory_document_v2", "metadata": { "id": "v2.0-design-decisions-001", "title": "v2.0 設計上の決定事項", "documentType": "generic", "path": "v2.0-design-decisions.json", "tags": [ "design", "decision", "architecture", "v2" ], "lastModified": "2025-03-21T07:21:59.910Z", "createdAt": "2025-03-17T13:40:00.000Z", "version": 1 }, "content": { "summary": "Memory Bank MCP Server v2.0の設計における主要な決定事項と背景", "decisions": [ { "id": "decision-001", "title": "JSONベースのドキュメント構造への移行", "context": "以前のバージョンではMarkdownを使用していたが、構造化データの管理や検索、フィルタリングが難しかった。将来的なデータベース移行への道筋も考慮する必要があった。", "decision": "JSON形式をプライマリな保存形式として採用し、Markdownをプレゼンテーション用として位置づける。", "rationale": [ "スキーマに基づく検証によるデータの整合性確保", "構造化データとしての操作が容易", "検索・フィルタリング機能の拡張が容易", "将来的なデータベース移行への道筋" ], "consequences": { "positive": [ "タイプセーフなスキーマによる堅牢性向上", "プログラムによるアクセスと操作が容易", "メタデータと内容の明確な分離" ], "negative": [ "実装の複雑性増加", "人間による直接編集が難しい", "マイグレーション作業が必要" ] }, "implementation": "JSONスキーマを定義し、ドキュメントタイプごとに専用のバリデーション処理を実装。マイグレーションツールを作成して既存のMarkdownを変換。" }, { "id": "decision-002", "title": "クリーンアーキテクチャの採用", "context": "元のコードベースは保守や拡張が難しく、責任分離が明確でなかった。", "decision": "ドメイン中心のクリーンアーキテクチャを採用し、依存関係が内側に向かうように設計する。", "rationale": [ "関心事の明確な分離", "テスト容易性の向上", "ビジネスロジックとインフラストラクチャの分離", "変更に強い設計" ], "consequences": { "positive": [ "コードの責任範囲が明確", "テストがより簡単", "ドメインロジックが純粋に保たれる", "将来的な拡張が容易" ], "negative": [ "初期の開発オーバーヘッド", "ボイラープレートコードの増加", "学習曲線" ] }, "implementation": "ドメイン、アプリケーション、インフラストラクチャ、インターフェースの各層を明確に分離し、依存性注入を使用して結合。" }, { "id": "decision-003", "title": "マルチリンガルサポートの導入", "context": "国際的なユーザーベースからの要望があり、複数言語でのサポートが必要だった。", "decision": "英語、日本語、中国語のサポートを追加し、言語固有のテンプレートとメッセージを提供する。", "rationale": [ "国際的なユーザーへのアクセス拡大", "ユーザー体験の向上", "地域ごとのカスタマイズ可能性" ], "consequences": { "positive": [ "より広範なユーザーベースにアクセス可能", "ローカライズされたユーザー体験", "国際的なコラボレーションの促進" ], "negative": [ "翻訳とメンテナンスのオーバーヘッド", "テスト複雑性の増加", "コンテンツ同期の課題" ] }, "implementation": "i18nインフラストラクチャを構築し、言語ファイルを外部化。ユーザーが言語を指定できるように環境変数とコマンドラインオプションを追加。" }, { "id": "decision-004", "title": "read_contextコマンドの導入", "context": "ユーザーは複数のコマンドを実行してコンテキスト情報を取得する必要があり、使い勝手が悪かった。", "decision": "ブランチメモリバンク、グローバルメモリバンク、ルールを一度に取得できる統合コマンドを作成する。", "rationale": [ "ユーザー体験の向上", "効率的なコンテキスト取得", "AI assistantとの統合の簡素化" ], "consequences": { "positive": [ "コマンド実行回数の削減", "統一されたコンテキスト表現", "AI assistantの効率向上" ], "negative": [ "応答サイズの増加", "処理時間の増加", "エラーハンドリングの複雑化" ] }, "implementation": "既存のコントローラーを拡張し、新しいread_contextコマンドを実装。オプションで各部分の取得を制御可能にする。" }, { "id": "decision-005", "title": "自動マイグレーション機能", "context": "ユーザーが手動でMarkdownからJSONに変換するのは手間がかかり、エラーが発生しやすい。", "decision": "サーバー起動時に自動的にMarkdownファイルを検出してJSONに変換する機能を追加する。", "rationale": [ "移行の労力削減", "エラーリスクの低減", "利用開始時の摩擦軽減" ], "consequences": { "positive": [ "シームレスな移行体験", "一貫したデータ形式", "ユーザーの技術的負担軽減" ], "negative": [ "予期しない変換による問題", "大量のバックアップファイル生成", "複雑なドキュメントの変換精度" ] }, "implementation": "MarkdownToJsonMigrator、MigrationBackup、MigrationValidator、ConverterFactoryクラスを実装し、起動時に自動実行するよう設定。" } ], "architectureModels": { "layerDependencies": "各層は内側の層のみに依存し、外側の層に依存しない。", "packageStructure": "src/{domain, application, infrastructure, interface, main}という明確な構造で、責任範囲を分離。", "dataFlow": "外部リクエスト -> インターフェース層 -> アプリケーション層 -> ドメイン層 -> インフラストラクチャ層 -> 永続化/外部システム" }, "technicalDebt": [ { "description": "一部のテストの無効化", "reason": "CI/CDパイプラインの問題を回避するため", "plan": "テストを修正し、将来のリリースで再有効化する" }, { "description": "Markdownのサポート継続", "reason": "後方互換性のため", "plan": "将来のリリースで段階的に廃止する" }, { "description": "ロギングの改善", "reason": "現在のログレベルと出力形式が最適でない", "plan": "構造化ロギングの実装と適切なレベル制御を導入する" } ] } }