適合性ルールパック

Rules grouped by type, with packs and a browsable catalog

ルールパックは、一般的なアーキテクチャパターンのベストプラクティスをエンコードした、厳選された適合性ルールのコレクションです。ルールを一から書く代わりにパックをインストールすれば、明確な方針に基づき実績のあるルールセットを数秒で導入できます。

なぜルールパックなのか？

多くのチームは、マイクロサービス、クリーンアーキテクチャ、イベント駆動システムといったよく知られたパターンに従っています。どのパターンにも、自動的に強制すべき制約があります：

  • マイクロサービス同士でデータベースを共有してはならない
  • ドメインレイヤーはインフラストラクチャのコードをインポートしてはならない
  • イベントはスキーマ契約に従わなければならない

ルールパックは、これらの原則を実行可能なガードレールに変えます。

利用可能なパック

パック ルール数 重点
Microservices 10 サービス境界、独立したデプロイ可能性、境界づけられた通信
Clean Architecture 9 レイヤー境界、ドメインの分離、ポート/アダプターの強制
Event-Driven 8 チャネル準拠、スキーマ要件、デッドレターキュー
API-First 8 契約の必須化、バージョニング、認証のドキュメント化
Security Baseline 8 ゲートウェイの強制、シークレット管理、外部アクセス制御

パックのインストール

archyl-developer スキルから

AI コーディングエージェントに次のように依頼します：

Install the microservices conformance rules pack

エージェントが Archyl MCP サーバーを呼び出し、1 回の操作ですべてのルールを作成します。

SDK から

import { ArchylClient } from "@archyl/sdk";

const client = new ArchylClient({
  apiKey: process.env.ARCHYL_API_KEY,
  organizationId: "your-org-id",
});

// Install a pack by name
await client.governance.installPack("microservices");

UI から

エージェントハブ > Packs に移動し、任意のパックの Install をクリックします。

各パックの内容

Microservices（10 ルール）

  • データベースを共有しない — 各サービスは自身のデータを所有しなければなりません。サービスをまたぐクエリは API 経由のみとします。
  • 独立したデプロイ可能性 — サービス間にコンパイル時の依存関係を持たせません。共有ライブラリはバージョン管理しなければなりません。
  • 境界づけられた通信 — サービスは、データベースへの直接アクセスやファイル共有ではなく、定義された API コントラクトまたはイベントチャネルを通じて通信します。
  • サービスの分離 — サービスをまたぐインポートは禁止です。各サービスは独自の依存関係ツリーを持ちます。

Clean Architecture（9 ルール）

  • ドメインレイヤーの純粋性 — ドメインコードは外部インポートを一切持ちません。フレームワークも ORM も HTTP も使いません。
  • 依存関係の方向 — 依存関係は内側を向きます。ハンドラーはサービスに、サービスはドメインに依存し、その逆はありません。
  • ポート/アダプターの強制 — インフラストラクチャの関心事（DB、HTTP、メッセージング）は、ドメインやサービスのレイヤーではなくアダプターパッケージに置きます。
  • インターフェース境界 — サービスは具体的な実装ではなく、インターフェース（ポート）を利用します。

Event-Driven（8 ルール）

  • チャネル準拠 — イベントのプロデューサーとコンシューマーは、宣言済みのイベントチャネルを使用しなければなりません。場当たり的なトピック作成は禁止です。
  • スキーマ要件 — すべてのイベントには定義済みのスキーマが必要です。型のないペイロードは禁止です。
  • デッドレターキュー — コンシューマーは、処理に失敗したメッセージのために DLQ を設定しなければなりません。
  • トピックの命名規則 — トピックは一貫した命名パターン（例：domain.entity.event）に従います。

API-First（8 ルール）

  • 契約の必須化 — すべての公開エンドポイントに、OpenAPI、gRPC、または AsyncAPI の契約が登録されていなければなりません。
  • バージョニング — API エンドポイントにはバージョンプレフィックス（/v1/、/v2/）を含めなければなりません。
  • 認証のドキュメント化 — セキュリティスキームを契約内にドキュメント化しなければなりません。
  • ドキュメント化されていないエンドポイントの禁止 — 対応する契約ドキュメントのないハンドラーファイルは違反として検出されます。

Security Baseline（8 ルール）

  • ゲートウェイの強制 — 外部トラフィックは API ゲートウェイまたはロードバランサーを経由しなければなりません。サービスを直接公開することは禁止です。
  • シークレット管理 — ソースコードにシークレット、API キー、パスワードをハードコードしてはなりません。環境変数またはシークレットマネージャーを使用します。
  • 外部アクセス制御 — 外部リクエストを受け付けるサービスは、認証とレート制限を強制しなければなりません。
  • TLS の必須化 — サービス間の通信はすべて TLS を使用しなければなりません。サービス間での平文 HTTP は禁止です。

ルールのカスタマイズ

パックをインストールした後も、すべてのルールを自由に編集できます：

  • 重大度の変更 — リスク許容度に合わない場合は、ルールを critical から medium に引き下げます
  • 特定ルールの無効化 — 不要なルールを個別にオフにできます。パック全体を削除する必要はありません
  • 設定の変更 — プロジェクト構成に合わせて、ファイル glob、パターン、許可するインポート、レイヤー定義を調整します

エージェントハブ に移動し、任意のルールの編集アイコンをクリックして変更します。

パックの組み合わせ

パックは追加方式です。複数のパックをインストールして、異なるアーキテクチャ上の関心事をカバーできます：

組み合わせ ユースケース
Microservices + API-First + Security Baseline セキュリティのガードレールを備えた API 駆動のマイクロサービスプラットフォーム
Clean Architecture + Security Baseline 厳格なレイヤー境界とセキュリティ衛生を備えたモノリス
Event-Driven + Microservices イベントソーシングによるマイクロサービスシステム
API-First + Clean Architecture 契約駆動のモノリスまたはモジュラーモノリス

2 つのパックに重複するルールが含まれている場合、Archyl が重複を排除するため、競合は発生しません。

コントリビュート

ルールパックはオープンソースです。新しいパックの提案、既存パックへのルール追加、問題の報告ができます：

次のステップ