DDDにおいてRDBMSとのインピーダンスミスマッチをどう扱うべきか？

Ryo Asai @ryoasai74

なるほど。P157「一般的に言えることだが、使っているフレームワークとは争わないこと。フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、詳細は捨て去る方法を模索すること。」#DDDjp

Ryo Asai @ryoasai74

P160「データベースをオブジェクトの格納先として見る場合には、マッピングツールの能力に関わらず、データモデルとオブジェクトモデルをかけ離れたものにしてはならない。」これは読み落としてはならないことですね。モデルと実装を結びつけ、無駄な間接層による複雑さを避けるべき。#DDDjp

Ryo Asai @ryoasai74

だから、レガシーDBの制約がなくスキーマを自由に定義できる場合は、たとえば、JPAのエンティティでそのままドメイン層をマップするようなシンプルな設計を心がけるべきかと思います。JPAをドメイン層で使わないという意見もありますが、時としてYAGNIの臭いも感じる。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

@ryoasai74 なかなか解釈は難しいところで、ドメインオブジェクト(実際はグローバルな識別子を持つエンティティ)はテーブルと現実的に対応づくというイメージです。それからかけ離れると現実的ではないないという解釈。トランザクション境界も集約単位という理解ですね。#DDDjp

Ryo Asai @ryoasai74

@j5ik2o DDDの本だと、時代からおそらくEJBを念頭においているところがあるのですが、DDDをどのように実装するかは使用する技術やDBの制約（占有か共有されるレガシーか）といった要素を考慮し、適切にマッピングする必要があるのかと解釈しました。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

@ryoasai74 一番悩ましい話題ですね。JPAをドメイン層に使うとやはりRDBMSの関心事がドメイン層に入ってくる経験が多いです。綺麗にレイヤー分けできないという経験です。どこまでこだわるかですが、そこのマッピングが一番難易度が高いですね。#DDDjp

Ryo Asai @ryoasai74

@j5ik2o P160の記述で「関係モデルと近づけておくため、オブジェクトの関係性が持つ豊かさを若干犠牲にすること。」という記述もありますね。この辺りが実践的モデラーらしさというかあるべきモデルを押し付ける原理主義的な方法論と違っているのかなと思います。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

JPAのアノテーションを使うとドメインオブジェクトっぽくモデリングできてDBMSの型の影響も受けにくいのですが、しかし全く影響を受けないということはなく、純粋なドメインオブジェクトを構築するのに両方のことを考える苦労が大変なんですよね。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

だから、プレーンなJavaだけで表現できるドメイン層と(インフラ層の中の)JPA層を分けていましたね。#DDDjp

Ryo Asai @ryoasai74

実際、私がずっと前に経験したプロジェクトでEJBとレガシーDBを使っているプロジェクトがあったのですが、あるアーキテクトがテーブルモデルとドメインモデルを明確に分けるべきと主張して、エンティティそのものを素直にマップするという私の意見と対立したことがあります。#DDDjp

Ryo Asai @ryoasai74

確かに複雑なオートバイの部品表を扱うドメインでOODBSを採用するという案もあったくらいなので、RDBMSを利用するということ自体が技術的には問題があったのかもしれません。ただO/RマップのレイヤとPOJOのレイヤの変換だけで大部分の工数を割くということになりました。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

@ryoasai74 ドメイン層とテーブル層のインピーダンスミスマッチをなるべく少なくすることも考えられるという捉え方しました。いずれにしても、レイヤーを混同しないでマッピングする方法があればよいと思います。#DDDjp

Ryo Asai @ryoasai74

そのプロジェクトでは部品の複雑な階層をたどることは本質的でなく、図面のCRUDができることが本質的だったのです。だから、無駄な苦労をかけたのに性能も悲惨になってしまった。素直にDBに近い設計で良かったのではと思っているのです。エヴァンスの経験談にも似た話がありますね。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

そもそもレイヤーが違うことでモデルの意図が違うのだから分けるという方針ですね。@daisuke_m の名エントリ http://bit.ly/kOnpYl まぁ、本質は関心事の分離ができればいいので、他によい方法があればいいと思います。 #DDDjp

Ryo Asai @ryoasai74

@j5ik2o いずれにしても、現状のSI案件では大部分RDBMSを採用することがが一般的という事実を考えて上でそのインピーダンスミスマッチにどのように対処していくべきかの実践的、かつ、バランスのよい解決策が求められると思います。#DDDjp

Ryo Asai @ryoasai74

@j5ik2o 「データベースをオブジェクトの格納先として見る」ことができるかどうかという点も考慮すべきなのでしょうね。一般的にはそのような幸運に恵まれないので、面倒でも間接層を設けなくてはならないことが往々にしてあるのでしょう。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

Seasarでは、S2Dxoを使って UI層のフォーム情報を持つDTOとエンティティを相互に変換するという方法を取っています。これは結構 現実的で成功しているモデルですね。#DDDjp

Ryo Asai @ryoasai74

@j5ik2o 逆にSeamの思想ではエンティティがPojoとしてフォームから永続化まで一貫して使用され、途中でDTOによる無駄な詰め替えを避けるという考え方をしますね。多くの場合これも極端な例ですが。Gavinはできるだけ間接層を少なくするのが好きみたいです。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

@ryoasai74 この辺りの話題がDDDを実践する上で壁になることは間違いないでしょうね。実装の具体例については本書の範囲外でしょうが、そこを考えないわけにいかないということですね。みなさんで議論できるといいですね。#DDDjp

Ryo Asai @ryoasai74

@j5ik2o そうですね。DDDは実装とモデルの結びつきが重要と言っているのですが、publishされている実例がまだまだ少ないのが問題な気がします。このあたりの事例を研究していく必要があると思います。#DDDjp

加藤潤一(かとじゅん) @j5ik2o

@ryoasai74 ドメイン層の立場から見ると、それが一番よいですね。そう考えると、NoSQLとかはマッピングしやすいのでしょうが、日常的にはRDBMSですからねｗ 何かしらFWで吸収されるとよいですね。#DDDjp

Ryo Asai @ryoasai74

@j5ik2o 少なくとも、DDDの原書が書かれた時代と比べてO/Rマッピングは無料で利用できる空気のような存在になっているし、FWの透過性も格段に進化してきているとは思います。今後もさらに研究されていくのでしょう。FWが進化すればあとはモデル化の技術のみが残ります。#DDDjp

bohnen（草食系SA） @bohnen

@ryoasai74 DBの制約が大きいRDB上ではJPAのエンティティをそのままドメインのエンティティとするのに賛成です。ただ、逆にテーブル設計にモデリングが引きずられることもあり、どちらがよいかと言われれば性能が出る方針を、という感じではあります。

bohnen（草食系SA） @bohnen

人間とシステムの実行モデルが明らかに異なることから、システムに人を合わせるか、人にシステムを合わせるかと言う選択が生じる。エンドユーザーは明らかに後者だが、開発者はどちらなのか。

bohnen（草食系SA） @bohnen

僕は先生から "somewhere in the middle" だと教わりました。だから設計は難しい、とも。あとは、「bestはない。betterしかない」とも。