聞きたいこと

SpringBootを用いてドメイン駆動開発の学習をしているのですが、ドメインとドメインの外のやり取りがしっくりこないので皆さんの意見を聞きたいです。
詳細は以下の通りです。

1. DB(Repository)とドメインの連携について

ドメイン駆動が、ドメインの開発に注力する為のものであるとはいえ、Webアプリケーションである場合、全体としてドメイン表現のDB永続化や逆に復元についても考える必要があります。
SpringではよくJPA(Hibernate)を使用しRepository経由でDBとのやり取りを行うかと思いますが、ここにドメインモデルの概念を導入すると、以下のオブジェクト間でデータ変換が必要になります。

ドメイン駆動におけるエンティティや値オブジェクト
JPA利用の為に使用する@Entity(データクラス)

(CQRSの様にクエリー結果格納用のDTOを作る場合も基本的には同様)

具体的にはFactoryやConvertクラスを作ることになり、単純ではあるものの初期実装コストはかりますし、その後の機能追加でも大抵の場合一緒に修正が必要になるかと思っています。
ここで疑問なのは以下の通りです。

ドメイン外の変換クラスの実装・管理コストは許容するしかないのでしょうか？※1
ドメインオブジェクト ⇔ DTO間の変換に伴い、ドメインにただのgetterを生やす必要ができてしまう(DTO -> ドメインはファクトリで何とかなる)がこれも仕方がないのか、それともリフレクション等で対応するのが一般的なのでしょうか？
トランザクションスクリプトと比べると、上記コストはかなり無駄が多いといった所感ですが、ドメイン駆動で開発している方もこのあたりの認識は変わらないのでしょうか？※2

※1 ドメイン駆動開発により、ドメインロジックとそのデータをドメインパッケージに凝集する事は成功しているので、それらを技術的な側面に適合させる為のコストを払うのは仕方ないという考え？
※2 トランザクションスクリプトによる開発のメリットであるともいえる?

2. クライアントとの連携について

RESTサービスにする場合、前述1項のDBの件と同様にjsonへの変換コストが発生するかと思います。
@JsonPropertyで対応できない事も無いですが、json構造の設計自由度は下がるのでやはりDBと同様に変換用のConvertクラスとDTOが必要になると考えています。

こちらも同様にドメイン外の実装コストは払うほかないでしょうか？

※ページ(html)を返却する場合は、比較的簡単かと思います。

3. そもそもSpringMVCとドメイン駆動の相性が悪い

Springは開発者をビジネスロジックの開発に集中できるようにするアーキテクチャになっていたと思うので、勝手にドメイン駆動開発に適していると思い込んでいましたが、そもそもこれが誤りでしょうか？

つまり、ドメイン駆動開発の様なオブジェクト指向をフル活用しているデータとその振る舞いを表現する様な設計はそもそも想定していないのでしょうか？
(Springにおける開発は、ビジネスロジックに集中するとは言っても、データクラスとロジックのみを扱う@Serviceクラスで分けて表現するという思想？)

追記

回答頂いた後も学習を続けた結果、「ドメイン駆動設計」の捉え方が悪かったかもしれないと気づきました。
エヴァンス本スタートだったので、同書籍で紹介されているようなエンティティや値オブジェクト等の形を意識しすぎていた。
現在は、あくまでドメイン駆動の本質は以下の点であるという考え方に変わった。

ドメイン層といったレイヤーを作り、ここにビジネスモデル(ロジック)を閉じ込める
技術や他システム間(DB、外部API等)のやり取りロジックは、ドメイン層以外の上位層(外側)で吸収する (※1)
各レイヤーの依存方向をドメイン層に向ける

※1：ここでいう"技術"はWebであればリクエスト/レスポンスのようなもののことであり、仮にビジネスのコアになるような技術ならドメイン層にすることもある。

以上から、別にドメイン層の設計を必ずエンティティや値オブジェクトの様に表現しなければならないというわけでもない。
その為、ドメイン駆動であってもドメイン層がデータ中心なアプローチで手続き的になる事もあり得る。
(勿論、データとロジックをカプセル化するオブジェクト指向的なものが、ドメイン駆動の説明にマッチしているとは思いますが...)

ちょっと頭が固すぎました^ ^

行動規範の内容に同意します

回答1件

ベストアンサー

多くの人がクリーンアーキテクチャを選択していたとしても、DOAアプローチかつドメイン駆動設計という選択をしても構わないと思いますよ。
データを詰め替える処理が工数の大半を占めてしまうような規模と複雑さの開発ではクリーンアーキテクチャは適さないでしょう。

クリーンアーキテクチャやヘキサゴナルアーキテクチャではプログラムのメインロジックを入出力方法に依存させないという方針なので、ある環境では入出力をコマンドラインでデータはファイルに保存、ある環境ではWebアプリとRDB、またある環境ではデスクトップアプリとKVSなどのように、様々な環境で同じドメインロジックを使うことが可能です。
もちろん、そういう要件がなければあえてそんなことをする必要はありません。
それでも多くの人がクリーンアーキテクチャを使用しているのはテストをしやすくする効果があるからです。
テストランナーをプログラムの入出力とみなして、プロダクションの入出力とテストの入出力の二種類を使い分けているわけです。

SpringBootはDDDをするためのフレームワークではないという点は私も同意です。
しかしクリーンアーキテクチャやヘキサゴナルアーキテクチャを用いてDDDをすることに何も障害はありません。

投稿2021/06/07 15:21

rysh

総合スコア874

kanetugu_70e

2021/06/07 15:58

周りにDDD経験がある人間が居らず、自身の理解から判断せざるを得ない状況で自信がありませんでしたが、やはり詰め替えの問題点はあるのですね。ただ、ご記載頂いたアーキテクチャの通り、入出力やフレームワーク・ライブラリとビジネスドメインの結合度を限りなく下げることができる点は、かなりのメリットだと思っているので引き続き色々試しながっらDDDについて学習していきたいと思います。テスト面については、あくまで各ドメインオブジェクトが小さくなり凝集度が高くなる事でテストの容易性が上がる位の理解でしたが、テストランナーをソフトウェアの入出力とみなすといった視点は無かった為、勉強になりました。ご意見・ご回答頂きありがとうございました!

行動規範の内容に同意します