アーキテクチャインサイト

ArchylのAI分析は、潜在的なアーキテクチャの問題を検出し、システム設計を改善するための推奨事項を提供します。

Archylが検出するインサイト

重大な問題

高優先度

中優先度

低優先度

アーキテクチャ分析の実行

単一プロジェクト分析

1. サイドバーのインサイトセクションに移動
2. プロジェクトを選択
3. 分析をクリック
4. 分析が完了するまで待機
5. 重要度別に結果をレビュー

組織全体の分析

すべてのプロジェクトを一度に分析:

1. メインナビゲーションからインサイトに移動
2. 全プロジェクトを分析をクリック
3. 組織全体の集約された結果をレビュー

インサイトの理解

各インサイトには以下が含まれます:

重要度レベル

• 重大: 即座の対応が必要
• 高: 早めに対処すべき
• 中: 可能な時に検討
• 低: あると良い改善

影響を受ける要素

インサイトは関連するすべての要素をリストし、ダイアグラムで表示するための直接リンクを提供します。

推奨事項

問題を解決するための実行可能なステップ:

推奨: APIゲートウェイとデータベースの間にキャッシュ層を追加し、
データベースへの直接接続を減らし、
耐障害性を向上させます。

関連ドキュメント

関連するベストプラクティスとアーキテクチャパターンへのリンク。

インサイトの管理

インサイトの非表示

インサイトが意図的なものまたは誤検出の場合:

1. インサイトをクリックして展開
2. このインサイトを非表示をクリック
3. オプションで理由を追加
4. メインビューから非表示になる

非表示インサイトの表示

非表示のインサイトをレビュー:

1. インサイトセクションに移動
2. 非表示を表示を切り替え
3. レビューし、オプションで非表示を解除

一括操作

複数のインサイトを選択して:

• 選択したものをすべて非表示
• チームメンバーに割り当て
• レポートとしてエクスポート

ベストプラクティス

定期的な分析

• 主要なアーキテクチャ変更後に分析を実行
• スプリント計画にインサイトレビューを含める
• インサイトの傾向を時間経過で追跡

影響度で優先順位付け

すべてのインサイトに即座の対応が必要なわけではありません:

1. 重大と高の重要度に最初に集中
2. 優先順位付けにビジネスインパクトを考慮
3. 意図的な逸脱を記録

チームと共有

• アーキテクチャレビュー用にインサイトレポートをエクスポート
• チームメンバーにインサイトを割り当て
• プロジェクト管理ツールで解決を追跡

一般的なインサイトと解決策

単一障害点

問題: 1つのサービスがすべての認証を処理。

解決策:

• 冗長な認証サービスを追加
• サーキットブレーカーパターンを実装
• 分散セッションストレージを使用

高結合

問題: フロントエンドが10以上のバックエンドサービスを直接呼び出し。

解決策:

• APIゲートウェイを導入
• Backend for Frontend（BFF）パターンを実装
• イベント駆動通信を使用

循環依存

問題: サービスAがBに依存、BがCに依存、CがAに依存。

解決策:

• 共通ロジックを新しいサービスに抽出
• イベント駆動アーキテクチャを使用
• サイクルを断つためにリファクタリング

孤立要素

問題: 接続が表示されないデータベース。

解決策:

• 使用するサービスとのリレーションシップを追加
• 使用されていない場合は削除
• 使用方法を説明するドキュメントにリンク

インサイトルールのカスタマイズ

組織ごとに異なるアーキテクチャ基準があります。Archylでは、チームの要件に合わせてインサイトを生成するルールをカスタマイズできます。

ルール設定へのアクセス

1. インサイトセクションに移動
2. ルールタブをクリック
3. 各ルールの設定を調整
4. 保存をクリックして変更を適用

変更を保存すると、Archylは新しい設定でアーキテクチャを自動的に再分析します。

利用可能なルール

単一障害点（SPOF）

障害時にシステム全体に影響を及ぼす可能性がある、受信依存関係が多すぎる要素を検出します。

アーキテクチャが意図的に特定の関心事を集約している場合は、しきい値を上げてください。データベースなどの重要なインフラは、しきい値の設定に関係なく、より厳しくチェックされます。

高結合

どちらの方向にも接続が過剰なコンポーネントを特定します。

受信しきい値は、多くのコンポーネントから依存されている要素を検出します。送信しきい値は、多すぎるコンポーネントに依存している要素を検出します。共有ライブラリを開発するプラットフォームチームは、プロダクトチームよりも高いしきい値を設定するとよいでしょう。

過接続要素

合計接続数（受信+送信の合計）が多すぎる要素をフラグ付けします。

これは高結合とは別の問題を捉えます。システムのあまりにも多くの部分に関わっているために、把握しにくくなっているコンポーネントです。

循環依存

AがBに依存し、BがCに依存し、CがAに依存する依存サイクルを検出します。

循環依存はテストを複雑にし、初期化時の問題を引き起こし、境界が不明確であることを示します。ほとんどのチームはこのルールを有効のままにしています。

孤立要素

他のコンポーネントとの接続がないアーキテクチャ要素を検出します。

孤立要素は、ドキュメントの欠落や、削除すべき非推奨サービスを示している可能性があります。

セキュリティ問題

外部システムからのデータベースへの直接アクセスなど、懸念されるパターンを検出します。

これらの検出結果の重要度は重大であり、ほとんどのチームがすぐに把握したい内容です。

ドキュメント不足

説明のない要素を報告します。

大規模なコードベースでレポートが膨大にならないよう、コンポーネントのドキュメントチェックは、コンポーネントの総数がこのしきい値を下回る場合にのみ実行されます。システムとコンテナは常にチェックされます。

組織全体の設定

インサイトルールはプロジェクトごとではなく、組織全体に適用されます。すべてのチームとプロジェクトに一貫したガバナンス基準を確保します。

デフォルトへのリセット

ルールタブのデフォルトにリセットをクリックすると、すべてのルールが元の設定に復元されます。

次のステップ

• AIによるディスカバリー - アーキテクチャを最新に保つ
• ドキュメント - アーキテクチャの決定を記録
• エクスポート - インサイトレポートのエクスポート