【.NET5】僕が有給を犠牲に解釈した何とも言えないDDD+CQRS実装サンプル

TryDDD.sln
- LibraryDomain.csproj(ドメイン層)
- LibraryApplication.csproj(アプリケーション層)
- LibraryInfrastructure.csproj(インフラストラクチャ層)
- TryDDD.csproj(プログラム全体のエントリポイント)

フォルダ

フォルダはこんな感じ

├─LibraryDomain
│  ├─Models
│  │  ├─Books
│  │  ├─BookStocks
│  │  └─Users
│  └─Services
├─LibraryApplication
│  ├─Commands
│  │  ├─Handlers
│  │  └─Requests
│  └─Queries
│      ├─Handlers
│      ├─RepositoryIf
│      ├─Requests
│      └─Results
├─LibraryInfrastructure
│  ├─Books
│  ├─BookStocks
│  ├─DataModel
│  ├─Queries
│  ├─Shared
│  └─Users
└─TryDDD

説明を添える

├─LibraryDomain：ドメイン層
│  ├─Models：
│  │  ├─Books：ドメインオブジェクトとか仕様オブジェクト + レポジトリやファクトリのIF
│  │  └─...
│  └─Services

├─LibraryApplication：アプリケーション層
│  ├─Commands：CQRSのC
│  │  ├─Handlers：コマンドを呼ぶためのエントリポイントみたいな
│  │  └─Requests：コマンド用のパラメータクラス(コマンドオブジェクト)
│  └─Queries：CQRSのQ
│      ├─Handlers：クエリを呼ぶためのエントリポイントみたいな
│      ├─RepositoryIf：クエリ用レポジトリのIF
│      ├─Requests：クエリ用のパラメータクラス(コマンドオブジェクト)
│      └─Results：クエリの実行結果用クラス(DTOみたいなもの)

├─LibraryInfrastructure：インフラストラクチャ層
│  ├─Books：レポジトリやファクトリの実装
│  ├─DataModel：データモデル。ドメイン層のドメインオブジェクトをデータソースに依存させないための射影的なもの
│  └─Queries：クエリ用レポジトリの実装

└─TryDDD：今回のプログラム群をテストで叩く全体のエントリポイント

ここから各層について細かく説明する
けど、概ね言葉が分かる人はもうgithubのレポジトリ見たほうが早いかも

ドメイン層

├─LibraryDomain：ドメイン層
│  ├─Models：
│  │  ├─Books：ドメインオブジェクトとか仕様オブジェクト + レポジトリやファクトリのIF
│  │  └─...
│  └─Services

├─LibraryDomain
│  │  LibraryDomain.csproj
│  │
│  ├─Models
│  │  ├─Books
│  │  │      Book.cs
│  │  │      BookId.cs
│  │  │      BookName.cs
│  │  │      IBookRepository.cs
│  │  │
│  │  ├─BookStocks
│  │  │      BookStock.cs
│  │  │      BookStockId.cs
│  │  │      IBookStockFactory.cs
│  │  │      IBookStockRepository.cs
│  │  │      RentalLimitCountSpecification.cs
│  │  │
│  │  └─Users
│  │          IUserRepository.cs
│  │          User.cs
│  │          UserId.cs
│  │          UserName.cs
│  │
│  └─Services
│          BookService.cs
│          BookStockService.cs
│          UserService.cs

ここはDDD的に割と素直な作りで特に言うことがない
ここにはCQRSの話は出てこないしね

ご存知の通りだと思うけどレポジトリやファクトリのIFがいるのは依存性逆転の原則のやつ

ドメインオブジェクトの中にはすごくかっこいい実装があるが、この形容は自画自賛ではない
この人の実装を参考にした

https://takap-tech.com/entry/2021/02/03/232823

内心で集約の切り方がいまいち怪しい気がしている
あと他の集約にIdを持たせたりしたほうがいいのか？とか...

また、申し訳程度に仕様オブジェクト( RentalLimitCountSpecification )を作ったけど微妙な気がしている

あとほんの少しだけテストを書いたけど、今回大変なので凍結した

├─LibraryDomainTest
│  │  LibraryDomainTest.csproj
│  │
│  ├─Models
│  │  └─Books

アプリケーション層

├─LibraryApplication：アプリケーション層
│  ├─Commands：CQRSのC
│  │  ├─Handlers：コマンドを呼ぶためのエントリポイントみたいな
│  │  └─Requests：コマンド用のパラメータクラス(コマンドオブジェクト)
│  └─Queries：CQRSのQ
│      ├─Handlers：クエリを呼ぶためのエントリポイントみたいな
│      ├─RepositoryIf：クエリ用レポジトリのIF
│      ├─Requests：クエリ用のパラメータクラス(コマンドオブジェクト)
│      └─Results：クエリの実行結果用クラス(DTOみたいなもの)

第1階層をコマンドとクエリをフォルダ単位で分けた
第1階層については、コマンドで特に言えることだけど最初に集約単位(例えばBooks)でフォルダを切るか迷った
けど結局コマンドもクエリも集約を跨ぐ事が多々ある気がしてやめた

├─LibraryApplication
│  │  LibraryApplication.csproj
│  │
│  ├─Commands
│  │  ├─Handlers
│  │  │      DeleteUserHandler.cs (これ使い忘れた)
│  │  │      LendBookHandler.cs
│  │  │      RegisterBookHandler.cs
│  │  │      RegisterUserHandler.cs
│  │  │
│  │  └─Requests
│  │          LendBookCommand.cs
│  │          RegisterBookCommand.cs
│  │          RegisterUserCommand.cs
│  │
│  └─Queries
│      ├─Handlers
│      │      GetAllBooksHandler.cs
│      │      GetAllUserHandler.cs
│      │      GetUserHandler.cs
│      │
│      ├─RepositoryIf
│      │      IQueryRepository.cs (本当はクエリ毎にレポジトリ切ったほうがいいかも)
│      │
│      ├─Requests
│      │      GetUserQuery.cs
│      │
│      └─Results
│              GetAllBooksResult.cs
│              GetAllUsersResult.cs
│              GetUserResult.cs
│

アプリケーションサービス(≠ドメインサービス)と呼ばれるものをコマンド・クエリのハンドラに分けたような形
厳密には「HandlerにRequestsフォルダのファイル(クエリ用パラメータクラス)を渡す」という作りで、これは上述したMediatRの実装を参考にした
※でも今回は非同期なAPIでもないのでMediatRは使っていない

https://qiita.com/wasimaru/items/5ad064aac7fc6f929cd1

ちょっと分かりにくいかもしれないので、具体的なコードで書くと、こんな感じに呼び出す

// 本当はDIとかする

// コマンド
var commandHandler = new HogeHandler(hogeRepository);
var commandRequest = new HogeCommand(name: "テスト")
commandHandler.Handle(commandRequest);
// クエリ
var queryHandler = new FugaHandler(hogeRepository);
var queryRequest = new FugaQuery(id: 1);
var result = queryHandler.Handle(queryRequest);

クエリ側にはRepositoryIF(リポジトリのIF)、Resultsがいるが、これがコマンドクエリの役割の違いの最たるもの
コマンド側は基本的に集約単位に存在するリポジトリを使ってCRUDのRead以外を行う
その際のWriteModelはDTO(インフラ層在中)を使う
クエリ側はユースケースに応じて独自のReadModelをResultsフォルダに用意し、独自のリポジトリを使うためここにRepositoryIFを設けている

今回に関して、それぞれの命名については少し難があって、 RegisterBookHandler はともかく、 GetAllBooksResult なんかは、そのユースケースが見えてこないのでよくない
例えば GetAllBooksForIndexView みたいな具体的な名前の方がいい
(と、Greg Youngは言っている)

インフラストラクチャ層

├─LibraryInfrastructure：インフラストラクチャ層
│  ├─Books：レポジトリやファクトリの実装
│  ├─DataModel：データモデル。ドメイン層のドメインオブジェクトをデータソースに依存させないための射影的なもの
│  └─Queries：クエリ用レポジトリの実装

├─LibraryInfrastructure
│  │  InitSqlite3.cs (今回SQLiteを使うので最初にそのテーブルを作成したり...などを行う)
│  │  LibraryInfrastructure.csproj
│  │
│  ├─Books
│  │      BookRepository.cs
│  │
│  ├─BookStocks
│  │      BookStockFactory.cs
│  │      BookStockRepository.cs
│  │
│  ├─DataModel
│  │      BookDataModel.cs
│  │      BookStockDataModel.cs
│  │      UserDataModel.cs
│  │
│  ├─Queries
│  │      QueryRepository.cs (本当はクエリ毎にレポジトリ切ったほうがいいかも)
│  │
│  ├─Shared
│  │      RepositoryBase.cs (各レポジトリの基底クラス。コネクションを管理してDisposeするための実装。実装微妙かも)
│  │
│  └─Users
│          UserRepository.cs

DataModelは

ドメイン層のドメインオブジェクトをデータソースに依存させないための射影的なもの

と書いたけど、今回分かりやすくいうとDapperでテーブルと1:1で結びつけるためのオブジェクト
※非DDD文脈ではEntityと呼ばれることが多い気がする

リポジトリやファクトリは集約単位(Books, BookStocks, Users)のフォルダの中にいて、複雑なRead、つまりクエリの処理がQueriesのQueryRepository.csにまとめられている

ユーザインタフェース(プレゼンテーション層)

これらのドメインを利用する層
.NET MVCでいうとControllerとかその辺

今回はコンソールアプリケーションなので薄い

└─TryDDD
    │  Program.cs
    │  TryDDD.csproj

特に言うことはないけど、一応DIをしている

上述したリポジトリのコネクションのDispose周り(IDisposable)はDIに任せておけばOKとのことなのでそれに従った
果たして本当にDisposeされるのか確認していないので何かあったらごめんなさい

利用イメージ

ユーザインタフェース(プレゼンテーション層)の実装を見るのが一番早い

「つくるもの(つくるドメイン)」の「テーブル」で書いた状態を作るような作業をしている

https://github.com/0mmadawn/DDD_CQRS_Sample/blob/main/TryDDD/Program.cs#L74

おわりに

という感じに作ってみたけど正しいのか正しくないのかわからない

個人的にはこの辺はかなり怪しい
一番入り口のとこじゃん！という気もするけど...

内心で集約の切り方がいまいち怪しい気がしている
あと他の集約にIdを持たせたりしたほうがいいのか？とか...

また、申し訳程度に仕様オブジェクト( RentalLimitCountSpecification )を作ったけど微妙な気がしている

あとテスト書けてないのでその時に破綻している箇所が出てくるかも
新規にIF作ったりすることになりそう

アクセサももっと工夫できるんじゃないかとか

とはいえ一番実装例がなくて困っていたCQRS周りの分割の実装はそこそこどうにかなったかも

会社に行っていない期間にせっせと書いたけど、この手の話は人と会話しないと作れないように思った

転職して次の会社でこの手の話が出来たらもうちょっとどうにかしたい

インドカレーファンクラブ

パソコン、カメラ

【.NET5】僕が有給を犠牲に解釈した何とも言えないDDD+CQRS実装サンプル

読まなくていいあらすじ

はじめに

読者想定

言い訳

全体的に参考にしたもの

つくるもの(つくるドメイン)

ドメイン

テーブル

つくったもの

アーキテクチャ

ソリューション