architecture

.NET アーキテクチャ

適用するタイミング

• 新規または進化中の .NET システムのアーキテクチャを選ぶとき
• レイヤー境界、ドメイン境界、またはサービスの分割を見直すとき
• クリーンアーキテクチャ、垂直スライス、CQRS、またはマイクロサービスが妥当か判断するとき

ワークフロー

1. 好みの図のスタイルではなく、ビジネスケイパビリティの境界と変更頻度を起点にします。
2. デフォルトではシンプルなモジュラーモノリスのパターンを使い、チームの自律性、規模、またはデプロイの境界が追加の運用コストを正当化する場合にのみ、マイクロサービスへ移行します。
3. ビジネスルールが本当に複雑な箇所では DDD と CQRS を適用します。効果が見込めない CRUD 中心のコードに、集約やコマンドパイプラインを無理に導入するのは避けます。
4. クリーンアーキテクチャを使う場合は依存関係を内側に向けます。ただし、所有責任を明確にしないまま形式的な手順を増やすだけのプロジェクトを追加するのは避けます。
5. 統合境界を明確にします。契約、ストレージの所有権、メッセージング、一貫性モデル、可観測性への期待を定義します。
6. ローカルでのオーケストレーション、サービスディスカバリー、開発者向けの可観測性がアーキテクチャの一部となる場合は、aspire を使います。

成果物

• システムの複雑さに見合ったアーキテクチャの方針
• 明確なプロジェクト境界と依存関係の境界
• 既存の構造を変更する場合の移行時の注意点やトレードオフ

検証

• 提案した構造によって、偶発的な複雑さが増すのではなく減っていること
• データの所有権と統合経路が明確であること
• 図にしやすいだけでなく、テスト可能で運用可能なアーキテクチャであること

参考資料

• references/patterns.md - クリーンアーキテクチャ、垂直スライス、DDD、CQRS、モジュラーモノリス、マイクロサービスの詳細な実装と C# 12 以降の例
• references/anti-patterns.md - 過剰な抽象化、貧血ドメインモデル、時期尚早なマイクロサービス化、カーゴカルト的なパターンなど、よくあるアーキテクチャ上の誤り