アーキテクチャインサイト
ArchylのAI分析は、潜在的なアーキテクチャの問題を検出し、システム設計を改善するための推奨事項を提供します。
Archylが検出するインサイト
重大な問題
| 問題 | 説明 |
|---|---|
| 単一障害点(SPOF) | システム全体の障害を引き起こす可能性がある、依存関係が多すぎる要素 |
| セキュリティ問題 | 外部システムからのデータベースへの直接アクセス、セキュリティ境界の欠如 |
| 循環依存 | メンテナンスとデプロイメントを複雑にする依存サイクル |
高優先度
| 問題 | 説明 |
|---|---|
| 高結合 | 他のコンポーネントとの接続が過剰なコンポーネント |
| 過接続要素 | インバウンドまたはアウトバウンドのリレーションシップが多すぎる要素 |
| 冗長性の欠如 | バックアップやフェイルオーバーメカニズムのない重要サービス |
中優先度
| 問題 | 説明 |
|---|---|
| 孤立要素 | 他のコンポーネントとのリレーションシップがない孤立した要素 |
| ドキュメント不足 | 説明やリンクされたドキュメントがない要素 |
| 命名の不一致 | 命名規則に従っていない要素 |
低優先度
| 問題 | 説明 |
|---|---|
| 最適化の機会 | 複雑さを軽減する可能性のある改善 |
| ベストプラクティスの提案 | C4モデルの慣例に基づく推奨事項 |
アーキテクチャ分析の実行
単一プロジェクト分析
- サイドバーのインサイトセクションに移動
- プロジェクトを選択
- 分析をクリック
- 分析が完了するまで待機
- 重要度別に結果をレビュー
組織全体の分析
すべてのプロジェクトを一度に分析:
- メインナビゲーションからインサイトに移動
- 全プロジェクトを分析をクリック
- 組織全体の集約された結果をレビュー
インサイトの理解
各インサイトには以下が含まれます:
重要度レベル
- 重大: 即座の対応が必要
- 高: 早めに対処すべき
- 中: 可能な時に検討
- 低: あると良い改善
影響を受ける要素
インサイトは関連するすべての要素をリストし、ダイアグラムで表示するための直接リンクを提供します。
推奨事項
問題を解決するための実行可能なステップ:
推奨: APIゲートウェイとデータベースの間にキャッシュ層を追加し、
データベースへの直接接続を減らし、耐障害性を向上させます。
関連ドキュメント
関連するベストプラクティスとアーキテクチャパターンへのリンク。
インサイトの管理
インサイトの非表示
インサイトが意図的なものまたは誤検出の場合:
- インサイトをクリックして展開
- このインサイトを非表示をクリック
- オプションで理由を追加
- メインビューから非表示になる
非表示インサイトの表示
非表示のインサイトをレビュー:
- インサイトセクションに移動
- 非表示を表示を切り替え
- レビューし、オプションで非表示を解除
一括操作
複数のインサイトを選択して:
- 選択したものをすべて非表示
- チームメンバーに割り当て
- レポートとしてエクスポート
ベストプラクティス
定期的な分析
- 主要なアーキテクチャ変更後に分析を実行
- スプリント計画にインサイトレビューを含める
- インサイトの傾向を時間経過で追跡
影響度で優先順位付け
すべてのインサイトに即座の対応が必要なわけではありません:
- 重大と高の重要度に最初に集中
- 優先順位付けにビジネスインパクトを考慮
- 意図的な逸脱を記録
チームと共有
- アーキテクチャレビュー用にインサイトレポートをエクスポート
- チームメンバーにインサイトを割り当て
- プロジェクト管理ツールで解決を追跡
一般的なインサイトと解決策
単一障害点
問題: 1つのサービスがすべての認証を処理。
解決策:
- 冗長な認証サービスを追加
- サーキットブレーカーパターンを実装
- 分散セッションストレージを使用
高結合
問題: フロントエンドが10以上のバックエンドサービスを直接呼び出し。
解決策:
- APIゲートウェイを導入
- Backend for Frontend(BFF)パターンを実装
- イベント駆動通信を使用
循環依存
問題: サービスAがBに依存、BがCに依存、CがAに依存。
解決策:
- 共通ロジックを新しいサービスに抽出
- イベント駆動アーキテクチャを使用
- サイクルを断つためにリファクタリング
孤立要素
問題: 接続が表示されないデータベース。
解決策:
- 使用するサービスとのリレーションシップを追加
- 使用されていない場合は削除
- 使用方法を説明するドキュメントにリンク
インサイトルールのカスタマイズ
組織ごとに異なるアーキテクチャ基準があります。Archylでは、チームの要件に合わせてインサイトを生成するルールをカスタマイズできます。
ルール設定へのアクセス
- インサイトセクションに移動
- ルールタブをクリック
- 各ルールの設定を調整
- 保存をクリックして変更を適用
変更を保存すると、Archylは新しい設定でアーキテクチャを自動的に再分析します。
利用可能なルール
単一障害点(SPOF)
障害時にシステム全体に影響を及ぼす可能性がある、受信依存関係が多すぎる要素を検出します。
| 設定 | 範囲 | デフォルト |
|---|---|---|
| しきい値 | 1-20 | 3 |
高結合
どちらの方向にも接続が過剰なコンポーネントを特定します。
| 設定 | 範囲 | デフォルト |
|---|---|---|
| 受信しきい値 | 1-50 | 4 |
| 送信しきい値 | 1-50 | 6 |
過接続要素
合計接続数(受信+送信の合計)が多すぎる要素をフラグ付けします。
| 設定 | 範囲 | デフォルト |
|---|---|---|
| しきい値 | 2-100 | 8 |
循環依存
AがBに依存し、BがCに依存し、CがAに依存する依存サイクルを検出します。
| 設定 | オプション |
|---|---|
| 有効 | オン/オフ |
孤立要素
他のコンポーネントとの接続がないアーキテクチャ要素を検出します。
| 設定 | オプション |
|---|---|
| 有効 | オン/オフ |
セキュリティ問題
外部システムからのデータベースへの直接アクセスなど、懸念されるパターンを検出します。
| 設定 | オプション |
|---|---|
| 有効 | オン/オフ |
ドキュメント不足
説明のない要素を報告します。
| 設定 | 範囲 | デフォルト |
|---|---|---|
| コンポーネント上限 | 1-500 | 20 |
組織全体の設定
インサイトルールはプロジェクトごとではなく、組織全体に適用されます。すべてのチームとプロジェクトに一貫したガバナンス基準を確保します。
デフォルトへのリセット
ルールタブのデフォルトにリセットをクリックすると、すべてのルールが元の設定に復元されます。
次のステップ
- AIによるディスカバリー - アーキテクチャを最新に保つ
- ドキュメント - アーキテクチャの決定を記録
- エクスポート - インサイトレポートのエクスポート