本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つDDD Systems & .NET Guidelinesについてです。
DDD Systems & .NET Guidelines
DDD Systems & .NET Guidelinesは.NETアプリケーションのアーキテクチャ設計（構造・責務分離・設計原則）に関するベストプラクティスです。
ドメイン中心設計（DDD）の思考に基づいて設計を行います。
以下のページからDDD Systems & .NET Guidelinesのインストールボタンをクリックして取得します。
github.com
インストールボタンを押してDDD Systems & .NET Guidelinesダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。
インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、Copilotは単純なコード生成ではなくアーキテクチャを意識した設計提案を行うようになります。
具体的にはCopilotは以下のような行動をとります。
レイヤードアーキテクチャを前提にする
Copilotは.NETアプリを次のような層構造で提案します。
- Presentation（UI / API）
- Application（ユースケース）
- Domain（ビジネスロジック）
- Infrastructure（DB / 外部）
これはクリーンアーキテクチャと呼ばれる構造です。
ドメイン中心設計（DDD）
Copilotはデータベースではなく「業務ロジック」を中心に設計するようになります。
具体的には以下を使う設計を提案します。
- Entity
- Value Object
- Aggregate
依存関係のルール（Dependency Rule）
依存関係の参照は外側 → 内側のみ許可します。
例えば、DomainはDBを知らず、ApplicationはUIを知らないような設計です。
これにより疎結合な設計になります。
責務分離（Separation of Concerns）
Copilotは次を厳密に分けます。
| 層 | 役割 |
|---|---|
| Domain | ビジネスルール |
| Application | 処理の流れ |
| Infrastructure | 技術処理 |
| Presentation | 入出力 |
モジュール化（Modular Monolith）
Copilotは機能ごとにモジュール分割を推奨します。
例えば以下のような構成にします。
Orders/ Users/ Payments/
これによりモジュール単位で独立性を持たせることができます。
以下のようなメリットがあります。
- 1つのアプリでも内部は分割している
- 将来マイクロサービス化しやすい
CQRS/イベント駆動を考慮
Copilotは必要に応じて以下を提案します。
- CQRS（読み書き分離）
- Event-driven architecture
インフラ依存を外に追い出す
Copilotは以下のような要素をInfrastructure層に閉じ込める設計を提案します。
- DB（EF Core）
- API
- ファイル
これにより以下のメリットがあります。
- テストしやすい
- 技術変更に強い
テストしやすい設計
設計の際にテストしやすい構造を前提に提案を行います。
具体的には以下の要素を考慮します。
- Domainは純粋なクラス
- DI（依存性注入）
- モック可能
.NETらしい実装パターン
Copilotは.NETでよく使われる構成を提案します。
例えば以下のような構成です。
- ASP.NET Core（API層）
- EF Core（DB）
- MediatR（CQRS）
- Dependency Injection
スケーラビリティを考慮
Copilotは最初からモノリス → マイクロサービスへの移行を考慮した設計を提案します。
