DDDにおいてRDBMSとのインピーダンスミスマッチをどう扱うべきか？ - Togetter
Twitterのつぶやきマッシュアップメディア!
まとめ
メニューを開く-
@ryoasai74 なかなか解釈は難しいところで、ドメインオブジェクト(実際はグローバルな識別子を持つエンティティ)はテーブルと現実的に対応づくというイメージです。それからかけ離れると現実的ではないないという解釈。トランザクション境界も集約単位という理解ですね。#DDDjp -
@ryoasai74 一番悩ましい話題ですね。JPAをドメイン層に使うとやはりRDBMSの関心事がドメイン層に入ってくる経験が多いです。綺麗にレイヤー分けできないという経験です。どこまでこだわるかですが、そこのマッピングが一番難易度が高いですね。#DDDjp
-
@ryoasai74 ドメイン層とテーブル層のインピーダンスミスマッチをなるべく少なくすることも考えられるという捉え方しました。いずれにしても、レイヤーを混同しないでマッピングする方法があればよいと思います。#DDDjp
-
そもそもレイヤーが違うことでモデルの意図が違うのだから分けるという方針ですね。@daisuke_m の名エントリ http://bit.ly/kOnpYl まぁ、本質は関心事の分離ができればいいので、他によい方法があればいいと思います。 #DDDjp
-
@ryoasai74 この辺りの話題がDDDを実践する上で壁になることは間違いないでしょうね。実装の具体例については本書の範囲外でしょうが、そこを考えないわけにいかないということですね。みなさんで議論できるといいですね。#DDDjp
-
@ryoasai74 ドメイン層の立場から見ると、それが一番よいですね。そう考えると、NoSQLとかはマッピングしやすいのでしょうが、日常的にはRDBMSですからねｗ 何かしらFWで吸収されるとよいですね。#DDDjp
-
@ryoasai74 DBの制約が大きいRDB上ではJPAのエンティティをそのままドメインのエンティティとするのに賛成です。ただ、逆にテーブル設計にモデリングが引きずられることもあり、どちらがよいかと言われれば性能が出る方針を、という感じではあります。 -
人間とシステムの実行モデルが明らかに異なることから、システムに人を合わせるか、人にシステムを合わせるかと言う選択が生じる。エンドユーザーは明らかに後者だが、開発者はどちらなのか。
-
僕は先生から "somewhere in the middle" だと教わりました。だから設計は難しい、とも。あとは、「bestはない。betterしかない」とも。
-
Content from Twitter
コメント