0LINEはじめにドメイン駆動設計でモデリング〜設計〜サンプルプログラム・テストコード作成までを一通りやってみての気づきや重要ポイントをまとめました。今回はリポジトリにフォーカスしてまとめています。本記事ではドメイン駆動設計のモデリング結果をベースに作業しています。モデリングについてはこちらを参照ください。ドメイン駆動設計のモデリング練習|データベーススペシャリストの過去問を題材にそもそもリポジトリと集約とは支払情報やユーザ情報など、システムで取り扱う情報はたいていデータベースなどに登録(永続化)してあとから取り出せる(再構築)必要があります。リポジトリ(保管庫)とはこの永続化、再構築を行う役割を担います。リポジトリにこの永続化、再構築の責務を持たせることで、データベースの具体的な操作(DBと接続する、接続失敗したときのハンドリング、SQL発行など)をユースケース層(アプリケーションサービス)などから切り離すことができ、データベースの具体的な操作が1箇所に集まり、プログラムの見通しも良くなります。この部分が>>具体的なデータベース操作ここから切り離されて、>>ユースケース層ユースケース層が本質的な処理だけ書けば良くなり、ごちゃごちゃせず見通しがよくなります。リポジトリパターンではインタフェースをきって、実装と切り離しています。依存関係をコントロールしてアプリケーションを柔軟にすることができます。今回のソースコードでは、PaymentCreateUseCaseがPaymentRepositoryを利用(依存)しています。PaymentRepositoryImplがPaymentRepositoryを実装(依存)しています。別のPaymentRepositoryPostgres的なモノを作ればPaymentCreateUseCaseや他のPaymentRepositoryに依存しているクラスに全く影響が出ません。このように依存関係をコントロールすること(依存性逆転の原則)で、アプリケーションをデータベースの具体的な操作に依存しない柔軟なものにできます。PaymentRepositoryMemory的なモノを作ってDBと接続せずにメモリ上でデータの永続化をしてテストするといった使い方もできます。ここまでがリポジトリについてでした。集約は本でこのように述べられていました。幸一郎)例えデータベース上でのテーブルの持ち方が分かれていても必ずセットで永続化、再構築したい単位が集約です。大きすぎる集約にしてしまうとロックを広い範囲でかけることになるので集約の単位には注意が必要。リポジトリのサンプルコードとテストコードまずは、作成したリポジトリのサンプルコードとリポジトリのテストコードのサンプルについてポイントに絞って紹介します。集約をそのままDBに登録したり、DBから取得したりできるリポジトリを作成しました。集約の範囲としては支払登録時に支払明細と支払方法明細を必ずセットで扱うようにしました。リポジトリとJOOQなどのORマッパーとエンティティ/値オブジェクトとの関係とリポジトリの役目を絵にするとこんなイメージです。実際にクエリを発行してDBデータ登録、データ取得を行う2つの役割を持たせています。支払リポジトリのインタフェース(ドメイン層)〜ドメイン駆動設計サンプルコード〜>>該当ソース(github)エンティティを渡すとDBへ登録する登録用のメソッドと、key情報を渡すとDBからデータを取得してエンティティを返却するメソッドを用意しています。支払リポジトリの実装(インフラ層)〜ドメイン駆動設計サンプルコード〜>>該当ソース(github)実際にJOOQ(ORマッパー)でDBとやりとりしているところです。登録の方は1つのエンティティを3つのテーブルに登録しにいくので、@Transactionalで1トランザクションとしてどれかのテーブルへの登録がコケたら、ロールバックできるようにしています。Record→エンティティ、エンティティ→Recordの変換用メソッドをそれぞれ用意しています。支払リポジトリのテストコード〜ドメイン駆動設計サンプルコード〜>>該当ソース(github)DBと繋いでテストをしています。@Transactionalでテストが終わったらロールバックできるようにしてInsertをなかったことにしています。登録してその後、登録した内容が取得できるかのテストを登録と取得のテストを一気に実施しています。個人的には効率よくて真似させてもらっています)ローカルで立てたDBと繋ぐので事前テーブル作ったり云々はFlywayで行う想定です。諸々Flyway周りについては以下にまとめています。前提となる開発環境構築手順などもまとめてあるので興味がある方は参考にしてみてください。desktop(postgreSQL、keycloak)、Flyway、DBeaverを利用したバックエンド開発環境構築リポジトリのサンプルコードを作成してみた感想や気付きまず、モデリングの時のように手が止まることはなかったです。実際に手を動かして実装してみて改めて感じましたが、ドメインモデル図があるとドメインモデル図→ソースコードへ落とし込む際にほとんど迷うことがなかったです。(複雑なビジネスロジックになるとそうはいかないかもしれませんが、、)現場で今までよく見かけていた、実装がほぼ終わってドメインエキスパートから違うと言われて作り直してまた設計。みたいなのが、ドメインエキスパートを巻き込みながらモデリングの段階でドメインモデル図の粒度でフィードバック受けつつブラッシュアップする。モデリング結果からスムーズに実装に落とすことができる。修正もモデリング結果をスムーズに実装に落とし込む仕掛けができているから早い。現場で導入するとそんなイメージかなと感じました。その素晴らしい仕組みを作るためにはリポジトリの詰め替え作業やエンティティ作って値オブジェクト作って、リポジトリ作って・・・などはその分最初に頑張る必要があるなと実感しました。自分で詰め替えを最初に頑張る。いう方針が先々のことを考えると良さそうに感じました。性能やメモリ使用率などなどについては、今まで僕が携わっていたシステムと比べて、インスタンスの作成や詰め替えなどなど入るのでどうなのかは個人的に興味がありますが。いえ、そんなとてつもない性能の要求がでるケースばかりではないでしょうし、メリットを活かせるケースは自分の過去を振り返っても十分あります。おまけドメイン駆動設計でモデリング〜コーディング〜テストコード作成までを実際に行ってみてのまとめ記事を作ったので興味がある方はご覧ください。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。