Evolutionary Architecture by Exampleが示す.NET設計の段階的な選択
プロジェクト概要：この .NET アーキテクチャガイドは、モジュラーモノリス・マイクロサービス・DDD・主要なアーキテクチャパターンを進化シナリオに沿って実例で結びつけます。
ひと目でわかる
- これは何？
- Fitnessドメインを題材に、単一プロジェクトからモジュール分離とマイクロサービスへ進む判断を読む。
- 誰に向いている？
- Evolutionary Architecture by Exampleが示す.NET設計の段階的な選択は、READMEに記載された機能と環境が自分の用途に合う場合に候補となります。適さない条件も同じ資料から切り分け、まず具体的なコマンド、対象ファイル、入力、出力を試験環境で確認してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 14 日前です。
- 何の言語で書かれている？
- 主に C# です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Project Paradoxを出発点にする
このC#リポジトリは、Clean、Onion、Hexagonal、戦術的DDD、モジュラーモノリス、マイクロサービスを単独の正解として並べません。ドメインを最も理解していない開始時に大きな決定を迫られる問題をProject Paradoxと呼び、状況に合わせて構成を変える読み物としてまとめています。
最初からマイクロサービス、複雑なオーケストレーション、ストリーミング、NoSQL、キャッシュを足すと、必要のない運用負荷を抱えます。逆に境界のないモノリスを放置すれば、機能を積み重ねた保守困難な塊になります。
evolutionary-architecture/evolutionary-architecture-by-exampleの確認項目1はREADMEに記載された範囲を示すもので、環境ごとの動作結果を代替しません。確認時は対象ファイル、入力、出力を対応させて記録します。利用者の権限やOSが違えば結果も変わり得るため、同じ手順を再実行できる形で残します。
Fitnessドメインを四章で追う
READMEの題材は代表的なFitnessビジネスドメインです。戦略的DDDと戦術的DDD、アーキテクチャパターンの選択と変化、モジュラーモノリスとマイクロサービスの混成、疎結合、.NETのMinimal API、意思決定ログ、クリーンなコーディングを扱います。
章は完成図を配るのではなく、理解が増えるにつれ設計を更新する流れを示します。各章のREADMEとリポジトリ内コードを対応させることで、概念名だけを覚える読み方を避けられます。フロントエンド、ログ実装、契約テストは対象外として明示されています。
evolutionary-architecture/evolutionary-architecture-by-exampleの確認項目2はREADMEに記載された範囲を示すもので、環境ごとの動作結果を代替しません。確認時は対象ファイル、入力、出力を対応させて記録します。利用者の権限やOSが違えば結果も変わり得るため、同じ手順を再実行できる形で残します。
Fitnetの垂直スライス
第1章は単一プロジェクト`Fitnet`を、業務プロセスごとのnamespaceで整理します。ControllerやEntityの技術分類ではなく、`SignContract`のような処理に関係するコードを近くへ置く垂直スライスです。モジュール間通信には単純なインメモリキューを使います。
この構成の判断は、機能追加へ早く進み、処理を移動・削除する範囲をnamespaceとして見つけやすくすることです。ここでのキューは実運用の分散メッセージ基盤を意味しません。第1章のコードで、境界と呼び出し方向を確認するのが最初の観察点です。
evolutionary-architecture/evolutionary-architecture-by-exampleの確認項目3はREADMEに記載された範囲を示すもので、環境ごとの動作結果を代替しません。確認時は対象ファイル、入力、出力を対応させて記録します。利用者の権限やOSが違えば結果も変わり得るため、同じ手順を再実行できる形で残します。
境界を分ける時点を示す章構成
第2章以降では、単一プロジェクトで保っていた境界をモジュールへ分離し、保守性を中心に検討します。READMEは、分離の理由をドメインの理解とシステムの複雑さに結び付けています。名称だけを移しても、依存方向やデータの責務が変わったことにはなりません。
混成構成では、すべてをサービス化するのではなく、分離する理由がある部分を選ぶ読み方が必要です。READMEが示すのは判断の道筋とサンプルで、特定の組織にそのまま適用できる移行計画ではありません。
evolutionary-architecture/evolutionary-architecture-by-exampleの確認項目4はREADMEに記載された範囲を示すもので、環境ごとの動作結果を代替しません。確認時は対象ファイル、入力、出力を対応させて記録します。利用者の権限やOSが違えば結果も変わり得るため、同じ手順を再実行できる形で残します。
実装と意思決定ログを照合する
バックエンド実装は.NET Minimal APIを使い、設計上の選択をArchitecture Decision Logとして残す構成です。READMEにはSerilogをログ候補、Pact Netを契約テスト候補として挙げていますが、実装済み機能としては約束していません。
確認時は第1章から順にソリューション構造、namespace、プロジェクト参照、APIの起点を読み、章が変わるたびに依存の向きがどう変わるかを記録します。READMEの説明とコードの差を埋める推測はしません。
evolutionary-architecture/evolutionary-architecture-by-exampleの確認項目5はREADMEに記載された範囲を示すもので、環境ごとの動作結果を代替しません。確認時は対象ファイル、入力、出力を対応させて記録します。利用者の権限やOSが違えば結果も変わり得るため、同じ手順を再実行できる形で残します。
学習用の適用範囲を決める
設計判断を段階的に説明する教材を探す.NET開発者には適しています。単一のテンプレート、性能ベンチマーク、完成済みの運用基盤を求める場合は、READMEの範囲を超えます。メタデータは3,505スター、534フォーク、9件のissue、MITライセンスです。
採用判断では`Chapter-1-initial-architecture/README.adoc`から読み始め、`Fitnet`の実装と対応する意思決定ログを確認します。コードを動かす場合も、章ごとの境界変更とテスト結果を別々に記録し、このリポジトリが示す教育上の判断と実サービスの要件を混同しないことが条件です。
evolutionary-architecture/evolutionary-architecture-by-exampleの確認項目6はREADMEに記載された範囲を示すもので、環境ごとの動作結果を代替しません。確認時は対象ファイル、入力、出力を対応させて記録します。利用者の権限やOSが違えば結果も変わり得るため、同じ手順を再実行できる形で残します。
編集部の結論
Evolutionary Architecture by Exampleが示す.NET設計の段階的な選択は、READMEに記載された機能と環境が自分の用途に合う場合に候補となります。適さない条件も同じ資料から切り分け、まず具体的なコマンド、対象ファイル、入力、出力を試験環境で確認してください。記載のない性能、互換性、運用保証は判断に含めません。
コミュニティノート