DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話

JJUG CCC 2017 fallDDD x CQRS - 更新系と参照系で異なるORMを併用して上手くいった話

2017/11/18株式会社ビズリーチ

松岡 幸一郎

● 松岡 幸一郎

● 株式会社ビズリーチ

● @little_hand_s● #ccc_m4

発表者紹介

最近こんなCMしてる会社です

自己紹介

Java

技術遍歴

SIer時代

Java

技術遍歴

SIer時代

Excel

技術遍歴

Excelはもういい

Java

技術遍歴

SIer時代

ExcelSpring BootDDD・CQRSVue.js

現職

DDD x CQRS

更新系と参照系で

異なるORMを併用して

上手くいった話

テーマ

DDD x CQRS

更新系と参照系で

異なるORMを併用して

上手くいった話

テーマ

ブログで細々とDDD布教中

http://little-hands.hatenablog.com/

なんですが

DDD x CQRS

更新系と参照系で

異なるORMを併用して

上手くいった話

テーマ

←今日のメイン

DDDとは

● Domain Driven Design(ドメイン駆動設計)の略称

● ドメインとは

○ 「アプリケーションの中心となる業務領域」のこと

● 原則

○ ドメインとドメインロジックを中心に設計する ( ≠ データモデル中心)○ 複雑なロジックをドメインモデルに寄せる (オブジェクト志向に則る)○ ドメインエキスパート(業務の専門家)と継続的にコミュニケーションし、モデルを改善し続ける

● メリット

○ ステークホルダー間のコミュニケーションが容易になる

○ ソースの可読性、変更容易性、メンテナンス性が高まる

● EricEvansによる定義

DDDとは

● Domain Driven Design(ドメイン駆動設計)の略称

● ドメインとは

○ 「アプリケーションの中心となる業務領域」のこと

● 原則

○ ドメインとドメインロジックを中心に設計する ( ≠ データモデル中心)○ 複雑なロジックをドメインモデルに寄せる (オブジェクト志向に則る)○ ドメインエキスパート(業務の専門家)と継続的にコミュニケーションし、モデルを改善し続ける

● メリット

○ ステークホルダー間のコミュニケーションが容易になる

○ ソースの可読性、変更容易性、メンテナンス性が高まる

● EricEvansによる定義

略

DDD x CQRS

更新系と参照系で

異なるORMを併用して

上手くいった話

テーマ

まず、

CQRSに関する誤解を解きたい

テーマ

まず、

CQRSに関する誤解を解きたい

テーマ

(※個人の見解です)

CQRSはイベントソーシングと

セットで行う必要がある

テーマ

CQRSはイベントソーシングと

セットで行う必要がある

テーマ

CQRSはイベントソーシングと

セットで行う必要がある

テーマ

CQRSは単独で適用できます

CQRSとは

● CQRSとは

○ Command Query Responsibility Segregation コマンドクエリ責務分離

○ 書き込み用のモデルと読み込み用のモデルを分ける設計パターン

CQRSとは

CQRSの提唱者

● Greg Young○ DDD + CQRS + イベントソーシングを推している

そのため、CQRSとイベントソーシングがセットで語られがち

→　本質的には別のもの

● なぜモデルを分ける必要があるのか？

● モデルを分けるとはどういうことなのか？

→ 背景から説明します

CQRS背景

● 一般的なシステムでは、書き込みと読み込みの両方が、

単一のデータストアで同じモデルを使用する

● テーブルに対応したオブジェクトがあり、それを使用してCRUD操作する

CQRS背景

DBData ModelUser Interface

Application

IF

IF

● システムが大きくなるほど、

○ 書き込み：制御は複雑になっていく

○ 読み込み：複数テーブルの情報をまとめて加工する必要性が高まっていく

→ 一つのモデルに関する処理がどんどん複雑になっていく

CQRSが必要な背景

● システムが大きくなるほど、

○ 書き込み：制御は複雑になっていく

○ 読み込み：複数テーブルの情報をまとめて加工する必要性が高まっていく

→ 一つのモデルに関する処理がどんどん複雑になっていく

CQRSが必要な背景

● そもそも、書き込み・読み込みで要件が大きく異なる

○ 整合性か、速度か

○ オブジェクトの形か、結合や集計した形か(モデル表現の違い)○ トラフィック数は圧倒的に読み込み処理が多い

○ パフォーマンス要件は異なることが多い

　　→ どこかにしわ寄せ、妥協が発生する

CQRSのステップ

CQRSのステップ

● 段階的CQRSa. 書き込み / 読み込みモデルを分離する

b. 書き込み / 読み込みデータストアを分離する

c. イベントソーシングと統合する

　→ 要件を見極めてどうするか判断すればよい

CQRS - 1.単一物理データストアモデル

● 書き込みと読み込みのモデルを別物として用意する

DBData Model

User Interface

Application

IF

IF

CQRS - 1.単一物理データストアモデル

● 書き込みと読み込みのモデルを別物として用意する

DBData Model

User Interface

Application

IF

IFDB

User Interface

IF

IF

Write Model

Read Model

CQRS - 1.単一物理データストアモデル

● 書き込みと読み込みのモデルを別物として用意する

● 書き込みモデル：

テーブル毎に対応したエンティティ等

● 読み込みモデル：

テーブルをJoinした結果、SQL viewの取得結果1行などを1モデルとする

　→ それぞれ適したモデルを扱えるので、処理効率が良い書き方ができる

　　コードがシンプルになる

DBData Model

User Interface

Application

IF

IFDB

User Interface

IF

IF

Write Model

Read Model

CQRS - 2.複数物理データストアモデル

● 書き込みと読み込みのデータストアを物理的に分離する

DBUser Interface

IF

IF

Write Model

Read Model

CQRS - 2.複数物理データストアモデル

● 書き込みと読み込みのデータストアを物理的に分離する

DBUser Interface

IF

IF

Write Model

Read Model

Write Data Store

Read Data Store

User Interface

IF

IF

Write Model

Read Model

CQRS - 2.複数物理データストアモデル

● 書き込みと読み込みのデータストアを物理的に分離する

● Read Data Store○ シンプルなのはread-onlyのレプリカ

○ 全く別の機構を選択することも可能 (Readをelastic searchにするなど)

　→ 参照/更新のストア分離により、それぞれの負荷に合わせたスケーリングが可能

　　異なるアーキテクチャのデータストアを利用可能

DBUser Interface

IF

IF

Write Model

Read Model

Write Data Store

Read Data Store

User Interface

IF

IF

Write Model

Read Model

● すべてのアクションを「イベント」として記録する設計パターン

既存のデータのupdateは一切しない

○ Writeモデルは「イベント」として記録される

○ Readモデルはそこから特定の形に変形される

MaterializedViewや物理的なデータを別途生成する、など

CQRS - 3.イベントソーシング

(@little_hand_s から参考資料たどれます「イベントソーシングの参考資料」 )

Write/ReadでORMを分ける

分離のメリット・デメリット

メリット デメリット

1.モデル分離 処理効率が良い書き方ができるコードがシンプルになる

readモデルにwriteモデルの制約を効かせられなくなる

2.データソース分離

Read / Writeを分離してスケールさせることができる設計の幅が広がる

データ同期の仕組構築 /メンテコストが必要

3.イベントソーシング

データ追跡しやすいミューテーション排除によるバグ抑止インピーダンスミスマッチとの決別

導入難易度がが一気に上がる導入・教育コストが高い

分離のメリット・デメリット

メリット デメリット

1.モデル分離 処理効率が良い書き方ができるコードがシンプルになる

readモデルにwriteモデルの制約を効かせられなくなる

2.データソース分離

Read / Writeを分離してスケールさせることができる設計の幅が広がる

データ同期の仕組構築 /メンテコストが必要

3.イベントソーシング

データ追跡しやすいミューテーション排除によるバグ抑止インピーダンスミスマッチとの決別

導入難易度がが一気に上がる導入・教育コストが高い

→ ORMも適正に合わせて使い分ければ、このメリットをより大きくできるのではないか？

CQRSのオプション

各オプションは要件に応じて好きに組み合わせて良い

単一物理ストア

複数物理ストア

データストア

Read / Write異なるモデル

Read / Write同じモデル

モデル

×

しない

する

イベントソーシング

×

単一ORM

複数ORM

ORM

×

CQRSのオプション

各オプションは要件に応じて好きに組み合わせて良い

単一物理ストア

複数物理ストア

データストア

Read / Write異なるモデル

Read / Write同じモデル

モデル

×

しない

する

イベントソーシング

×

→ メリット/デメリット、コストを考慮し、今回はこのような構成を選択

単一ORM

複数ORM

ORM

×

Write/Read ORMの要件

● Write Model ORM○ オブジェクト志向でモデルに振る舞いをもたせたい

・DDDの思想を反映

○ テーブルに対応したオブジェクト

Write/Read ORMの要件

● Write Model ORM○ オブジェクト志向でモデルに振る舞いをもたせたい

・DDDの思想を反映

○ テーブルに対応したオブジェクト

● Read Model ORM○ 複数テーブルをjoinしたり、集計したりしたい

○ 効率の良いクエリが書きたい

○ 実行されるクエリを制御したい

Write/Read ORMの要件

● Write Model ORM○ オブジェクト志向でモデルに振る舞いをもたせたい

・DDDの思想を反映

○ テーブルに対応したオブジェクト

● Read Model ORM○ 複数テーブルをjoinしたり、集計したりしたい

○ 効率の良いクエリが書きたい

○ 実行されるクエリを制御したい

　→ この要件に合うようにORMを選定する

ORMのパターン

中心 SQLロジックの組み込み方法 代表的プロダクト

オブジェクト中心

オブジェクトリレーショナルマッピングを通じてJavaに組み込む

Hibernate、(ActiveRecord)

SQL中心 Java外 - XMLなどの設定ファイル MyBatis、SQL view、ベンダー特有のストアドプロシージャ

Java内 - String文字列 JDBC、JPAネイティブクエリ

Java内 - 独自DSL jOOQ、JPQL

ORMのパターン

中心 SQLロジックの組み込み方法 代表的プロダクト

オブジェクト中心

オブジェクトリレーショナルマッピングを通じてJavaに組み込む

Hibernate、(ActiveRecord)

SQL中心 Java外 - XMLなどの設定ファイル MyBatis、SQL view、ベンダー特有のストアドプロシージャ

Java内 - String文字列 JDBC、JPAネイティブクエリ

Java内 - 独自DSL jOOQ、JPQL

　→ 先述の要件を踏まえ、3つのORMでメリット/デメリット検討

jOOQとは

● DBスキーマからDBアクセス用オブジェクト生成

● DSL中心でクエリビルド、実行できるORM● かなりSQLに近い書き方、かつタイプセーフにSQLが書ける

メリット デメリット

Hibernate(Spring Data JPA)

モデルに振る舞いを持たせやすいSpringDataJPAがDDDを想定した仕様

仕様の理解しにくさ、キャッシュなどのトラブ

ル、想定外の挙動　etc..

MyBatis SQLを直接かけるのでシンプル、安心 SQLがテキスト記述、XMLに設定を書くのは今時結構辛い

jOOQ タイプセーフなDSLで書きやすい、読みやすい

オブジェクトリレーションの表現に制限あり

ORM選定

メリット デメリット

Hibernate(Spring Data JPA)

モデルに振る舞いを持たせやすいSpringDataJPAがDDDを想定した仕様

仕様の理解しにくさ、キャッシュなどのトラブ

ル、想定外の挙動　etc..

MyBatis SQLを直接かけるのでシンプル、安心 SQLがテキスト記述、XMLに設定を書くのは今時結構辛い

jOOQ タイプセーフなDSLで書きやすい、読みやすい

オブジェクトリレーションの表現に制限あり

ORM選定

→Writer Model ORMにHibernate、Read Model ORMにjOOQを採用

CQRSを適用するためのアーキテクチャ

● 一般的な3層アーキテクチャの問題

○ Write/Readのモデル使用範囲を明確に分けられない

○ BusinessLogic層がFatになりやすい

アーキテクチャ

Business Logic

Data

User Interface

Infrastructure

● 業務ロジックをドメイン層に凝集する

● アプリケーションサービス層はドメイン層が許可した操作を必要に応じて呼ぶ

● この辺りはDDDの思想に基づいた設計

アーキテクチャ

Business Logic

Data

User Interface

Infrastructure

ApplicationService

DomainModel

User Interface

Infrastructure

(@little_hand_s から参考資料たどれます 「ドメイン駆動 + オニオンアーキテクチャ概略」 )

interface

アーキテクチャ

ApplicationService

DomainModel

User Interface

Infrastructure

ApplicationService

DomainModel

User Interface

Infrastructure実装クラス

● ドメイン層をPOJOにするために依存関係を逆転する

● ドメイン層が公開したIFに対してインフラ層が実装する設計

● ドメイン層をWrite Model (ドメインモデル)とRead Modelに分割する

● インフラ層の実装クラスをWriteとReadで異なるORMで実装する

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

ApplicationService

DomainModel

User Interface

Infrastructure

interface

実装クラス

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImpl

Spring Data JPA

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImplHibernate

Hibernate(アノテーションだけ )

Spring Data JPA

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImpl jOOQHibernate

Hibernate(アノテーションだけ )

サンプルコード

サンプルコード

TaskタスクIDタスク名ステータス

UserユーザーIDユーザー名

作成者

担当者

● シンプルなタスク管理アプリケーションを想定

● タスクの制約

○ 作成時の制約

■ 「作成者」と「担当者」として実在のユーザーを持つ

■ 常に「未完了」状態で作成

○ 変更時の制約

■ 名前は変更できない

■ 完了/未完了の制御だけできる

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImpl

Hibernate(アノテーションだけ )

サンプルコード Domain Model(entity, repository)Entity

Repository

ポイント

①entityが保持する値はUserのIdでLong型だが、

引数をUserにすることでTypeSafeになる

②必ず"未完了"の状態でインスタンス生成、

　という制約をコンストラクタで表現

③ステータス更新用のメソッドは公開されているが、

nameは更新用メソッドを公開しないことにより

「名前を変更できない」という制約を表現

①

②

③

コンストラクタと公開メソッドで制約を表現

コンストラクタ

状態遷移用メソッド

(@little_hand_s から参考資料たどれます 「モデルでドメイン知識を表現するとは何か」 )

サンプルコード Application ServiceApplicationService(新規作成)

ApplicationServiceの引数 ApplicationServiceの戻り値

サンプルコード Application ServiceApplicationService(更新)

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImpl

ポイント

・POJOで引数と戻り値の関係だけ定義

→「ライブラリ何使うかは任せるけど、

この条件で指定したらこういう形で返してね」

という宣言をしている

サンプルコード queryServiceクエリモデルのサービス IF

引数

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImpl jOOQ

サンプルコード queryServiceImplその他のクエリ部分

①クエリライクにJavaコードでselect, from, join条件を書いている

②resultをfetch後に戻り値の方に

mapしたものをreturnしている

③条件指定の方法は次のページ

①

②

③

・引数オブジェクトの値をjOOQのConditionオブジェクトにマッピング

・引数オブジェクトのパラメータを取得するメソッドをOptionalで返せば、

　値があるときだけ条件指定、ということも可能

・引数のパラメータを増やせば検索の拡張も簡単

サンプルコード queryServiceImpl条件指定部分

Spring Data JPA

アーキテクチャ

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Repository

Entity

Repository Impl

<<interface>>Query Serivce

DTO

Query SerivceImpl jOOQHibernate

Hibernate(アノテーションだけ )

導入結果

導入結果

● 実際どうだった？

導入結果

● 実際どうだった？

→かなり使い勝手が良いです！！

導入結果

● 実際どうだった？

→かなり使い勝手が良いです！！

● Read Model○ Hibernateの得意な部分は活かしつつ、

参照系ではまりがちなHibernateの使い方に悩む時間を一切カット

(クエリを書いた通りに動く)○ 検索条件の拡張も快適

● 実際どうだった？

→かなり使い勝手が良いです！！

● Read Model○ Hibernateの得意な部分は活かしつつ、

参照系ではまりがちなHibernateの使い方に悩む時間を一切カット

(クエリを書いた通りに動く)○ 検索条件の拡張も快適

● Write Model○ DDDとSpring Data JPAの相性は抜群

　RepositoryのIFだけ書けば実装クラスを作ってくれるのはとても楽

○ writeモデルに振る舞いを凝縮している安心感、読みやすさ◎

導入結果

Q&A

Q&A● そもそも2つのORM同時に使っていいの？

Q&A● そもそも2つのORM同時に使っていいの？

→前述の通りjOOQ公式で紹介されている使い方

(@little_hand_s から参考資料たどれます 「jOOQ関連リンク」)

Q&A● テストはどうしている？

Q&A

● テストはアプリケーション層のメソッドに対して書く(ちなみにspock)

● メリット：○ 費用対効果が良い○ 内部のリファクタがしやすい○ アプリケーションサービス層で担保すれば、

呼び出し元がAPIだろうが画面だろうがwatcherだろうが安心感がある

● デメリット：○ テストでのDB実行環境構築が必要

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

● テストはどうしている？

Q&A● 要件として参照と更新を同時に行う必要がある場合は？

例：ある情報を参照したら参照ログを残したい

Q&A● 要件として参照と更新を同時に行う必要がある場合は？

例：ある情報を参照したら参照ログを残したい

● 対策1：ApplicationServiceを複数呼び出す処理を書く

ファサードのようなレイヤなど。

通常のApplicationServiceとは区別するのがよい

● 対策2：ドメインイベントを発行してWatcherで拾い、非同期的に更新を行う

Q&A● アプリケーションサービスはコマンド系・クエリ系でクラスを分ける？

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

Q&A● アプリケーションサービスはコマンド系・クエリ系でクラスを分ける？

→ 分けたほうが使用するモジュールにに間違いないことが判別しやすい。

でもどちらも可

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

● QueryServiceはUIから直接参照させてもよいのでは？

Q&A

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Query Serivce

DTO

Query SerivceImpl

● QueryServiceはUIから直接参照させてもよいのでは？

→どちらでも可、要件次第。

　今回はApplicationServiceを挟んでよかった。

○ テスト単位がApplicationServiceというレイヤで統一できる

○ 単純な条件抽出以外の処理を分岐したい場合、

その制御をApplicationServiceに任せられる

■ 操作ユーザーの情報に応じて

処理を分岐

■ 権限制御、抽出条件変更など

Q&A

ApplicationService

DomainModel

QueryModel

User Interface

Infrastructure

<<interface>>Query Serivce

DTO

Query SerivceImpl

まとめ

まとめ

● CQRSは要件に応じて柔軟にやり方を変えられる

● Write/Readモデルを分けるときにORMを分けるのは、

モデルを分けるメリットを大きくできる

● ぜひご検討してみてください

● ご意見、ご質問は @little_hand_s もしくは#ccc_m4 まで

ありがとうございました