デザインガイド
進化するように設計されたPHPアプリケーションアーキテクチャ
優れたアーキテクチャは、ルールの変更、システムの統合、製品の運用にかかるコストを削減します。その品質は、レイヤーの数ではなく、意思決定と納品によって評価されます。
主な考え方
- モデルの機能と責任。
- 契約内容とデータ所有権を明確にする。
- チームと業務に適した配布方法を選択してください。
- 決定事項を記録し、実際の変化を通して検証する。
1. ドメインから始めます
関係者、プロセス、ルール、例外、および用語について説明します。技術的な境界は、フォルダやテーブルではなく、ビジネス上の責任を反映している場合に、より安定したものとなります。
- ビジネス能力。
- 規則と不変量。
- 出演者と許可について。
- 重要な出来事や決定。
2. 設計上の制約
すべてのコンポーネントには、変更の理由、インターフェース、そして所有者が必要です。有益な境界は共有知識を減らし、人為的な境界は真の独立性を伴わない変換と調整を増やします。
- それが知っていること、そして隠していること。
- 入力、出力、およびエラー。
- 許可されている依存関係。
- 契約テスト。
3. データを意思決定の手段として扱う
信頼できる情報源、一貫性、保持、移行を明確に定義する。テーブルを共有すると高速に感じられるが、目に見えない契約が生まれ、進化、セキュリティ、監査が困難になる。
- 所有権とライフサイクル。
- 即時的または最終的な一貫性。
- 歴史とトレーサビリティ。
- プライバシーとアクセス。
4. モノリス型か分散型かを選択する
モジュール型のモノリスは、チームと運用が共有されている場合に効果的な場合が多い。一方、境界、提供方法、規模、責任範囲が明確に異なる場合は、独立したサービスが適している。
- チームの規模と自律性。
- 独立したリリースの必要性。
- 機能別の負荷と可用性。
- ネットワーク、可観測性、および一貫性にかかるコスト。
5. 運用を考慮した設計
アーキテクチャには、構成、リリース、復旧、監視、およびサポートが含まれます。診断または復旧できないコンポーネントは、完全ではありません。
- 環境設定。
- ログ、メトリクス、トレース。
- リリースとロールバック。
- バックアップとリカバリ。
6. 決定事項を常に有効に保つ
ADR（代替的紛争解決）またはその他の簡略な形式で、背景、代替案、および結果を記録してください。制約条件が変更された場合は、決定内容を見直してください。文書を脈絡のないポリシーにしないでください。
- 決定と期日。
- 状況と力。
- 却下された代替案。
- 結果とレビューシグナル。
この決定に関連するコンテンツ
診断、処置、または関連する経験を継続してください。
ガイドをアプリケーションに適用してください
私たちは、評価を実施に結びつけることなく、状況、証拠、選択肢を検討します。