Kuchitama Tech Note

はてな記法がいつまでたっても覚えられないので、はてなダイアリーからマークダウンが使えるこっちに引っ越してきました。

Scala界隈でDDDが大いに盛り上がったのでログをまとめましたよ-その1

scala DDD

以前、ScalaJpのgitter.imでDDDについて議論が盛んに行われてたけど、いずれログが消えちゃうのがもったいなくて、ここに内容を貼付けます。

scalajp/public - Gitter

要約すると実践DDD本出たらみんなで読もうぜ。ってことで。

実践ドメイン駆動設計 (Object Oriented Selection)

実践ドメイン駆動設計 (Object Oriented Selection)

ホントは、自分のブログとかじゃなくてGistとかがいいんだろうけど、見た目を整えるのが一番楽なので、ここに掲載しておきます。 一応、最初にまとめるにいたった経緯↓

xuwei-k 2015年2月24日
gitter、無料だとログの保存期間2週間って話だったけど、実は現状全部残ってる https://gitter.im/scalajp/public/archives/2014/10/02

Kuchitama 2015年2月24日
え、そうなんですか？

xuwei-k 2015年2月24日
最低2週間を保証するだけで、残せる分は多めに残してくれるのかも？

Kuchitama 2015年2月24日
なるほど。

xuwei-k 2015年2月24日
まぁいつ消えるかわからないし、まとめるならまとめたほうがいいとは思うけど

Kuchitama 2015年2月24日
2週間以内にやりますｗ

2月23日

すべては @kawachi さんから始まったのであった。

tkawachi 2015年2月23日
実戦 Scala で DDD の話何回か出てきて、DDD本読まないとなあと思ってるところです。DDDのレポジトリってインフラ層ですよね。インフラ層はドメイン層に依存しないですよね。レポジトリは戻り値や引数にドメイン層のクラスを含みますよね。レポジトリはインフラ層ですよね。あれ？インフラ層がドメイン層に依存してる？となったのですが、 Scala + DDD やっている方に誤りを指摘していただきたく。

gakuzzzz 2015年2月23日
インフラ層はドメインのAPIに依存するのでは

tkawachi 2015年2月23日
ドメイン層のインタフェースと実装をわけて、インフラ層はドメイン層のインタフェースに依存する形？

gakuzzzz 2015年2月23日
コア<- ドメイン <- インフラ <- アプリケーション <- プレゼンテーション 的な依存関係だったような はい、そんな感じですね。

tkawachi 2015年2月23日
インフラ層はドメイン層の下層なので、ドメイン層はインフラ層に依存していいという認識です。 ドメインAPI <- インフラ <- ドメイン <- アプリ <- UI 的な感じになるのかな？

kiris 2015年2月23日
このあたりの話ですかね

インフラストラクチャ層 - 上位のレイヤを支える一般的な技術的機能を提供する。 - これには、アプリケーションのためのメッセージ送信、ドメインのための永続化、ユーザインタフェースのためのウィジェット描画などがある

gakuzzzz 2015年2月23日
こんなイメージでした。

ドメイン駆動設計とオニオンアーキテクチャ

xuwei-k 2015年2月23日
DDD おじさんの登場が待たれる

gakuzzzz 2015年2月23日
オニオンアーキテクチャもなんか色々反論でてて何が良いのやら……というわけで実戦DDD本が待ち遠しい今日この頃

todesking 2015年2月23日
Coreってどこ由来の用語なんだろう。エヴァンスのDDD本には出てこなかったような ドメイン層: "ビジネスの状況を反映する状態はここで制御され使用されるが、それを格納するという技術的な詳細は、インフラストラクチャに移譲される" (エヴァンスのDDD本)

todesking 2015年2月23日
実際にインフラ層とドメイン層の橋渡しをするのがリポジトリってやつですね(リポジトリ自体はこれはインフラ層に所属してるって認識でいいんだろうか)

kiris 2015年2月23日
リポジトリはドメイン言語で記述しない(コレクションとして振る舞う)ので、インフラ層に所属しているという認識でよかったかと

tkawachi 2015年2月23日
かとうさんのペットストアみてたんですが、domain 層と思しき package に JDBC という word が出てきてよくわからなくなったんですよね... https://github.com/j5ik2o/spetstore/blob/master/app/com/github/j5ik2o/spetstore/domain/infrastructure/support/RepositoryOnJDBC.scala あ、これインフラ層なのか

todesking 2015年2月23日
domain.{infra, lifecycle, model}

daiksy 2015年2月23日
実戦DDD本超読みたい

gakuzzzz 2015年2月23日
かとうさんのペットストア、domain と並列した infrastructure と domain配下の infrastructure がありますね。どう使い分けてるんだろう？

tkawachi 2015年2月23日
それ、僕も疑問です… 挙げていただいたオニオンアーキテクチャの説明ではインフラ層が最上位に見えますね。。 DDD本ではインフラ層が最下層なので、混乱してしまう

todesking 2015年2月23日

インフラストラクチャは最外層にあり，データベースやユーザインターフェース，外部サービスなど，さまざまなテクノロジ用のアダプタを含んでいる

DDDとは定義が違うっぽいですね

tkawachi 2015年2月23日
DDDのインフラ

これには、アプリケーションのためのメッセージ送信、ドメインのための永続化、ユーザインタフェースのためのウィジェット描画などがある

と違いがわからないなあ

todesking 2015年2月23日
あっ、本当だ。同じことを言っているんだろうか。 オニオンアーキテクチャの提唱者(?)の図を見るとInfoQと違ってて混乱してきた…… http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

tsukaby 2015年2月23日
お、なんだか興味深い議論が。自分もかわちさんと同じようにDDDのinfraまわり疑問でした。 domainはinfraに依存するからinfra層ってそうそう簡単に取り替えできないような気も・・・しかしDDDよく知らんしなー・・・と思いながらかとうさんの発表聞いてました。

gakuzzzz 2015年2月23日
うお、InfoQと元記事の図だいぶ違いますね……

todesking 2015年2月23日

domainはinfraに依存するからinfra層ってそうそう簡単に取り替えできないような気も

domain全体がinfraにベッタリ依存するわけではなく、repositoryを経由することになるので分離は容易だと思われます (ただし、リポジトリのAPI設計はインフラ層の実装の影響を受けるため、RDBをKVSに差し替えるレベルの変更が入った場合は影響を免れないでしょう)

xuwei-k 2015年2月23日
本当に差し替え可能にするなら、こうすべきだろ http://d.hatena.ne.jp/xuwei/20140703/1404356954 って以前書いたら、べつにDDDではそれは必須じゃないといわれた 「repositoryを経由することになるので分離は容易」が個人的にとても懐疑的で、ヘタすると謎に層が増えるだけで、全く使いやすくならない、というのが発生しがちな気がしている まぁ全部ごちゃまぜで密結合よりはマシだろうけど

tsukaby 2015年2月23日
なるほど、ありがとうございます。勉強になります。

todesking 2015年2月23日
実践者の意見だ(´･_･`)

xuwei-k 2015年2月23日
かとうさんも、そのあたり(層をきちんと分けるか否か？)は、パフォーマンスのチューニングのしやすさとか考えると、分けすぎてもあれだし、バランスが必要というかプロジェクト毎に考えるべき的なこと言ってた気がする(かなりうろ覚え)

taisukeoe 2015年2月23日

(ただし、リポジトリのAPI設計はインフラ層の実装の影響を受けるため、RDBをKVSに差し替えるレベルの変更が入った場合は影響を免れないでしょう)

あれ、リポジトリのAPIはデータソースの種類からの影響は受けるべきではない、という認識でいましたが、ここについて何かソースってありますか？

「内部で何をしていても、外部からはコレクションのように見える」など、46スライド目〜を参照してます。 http://www.slideshare.net/j5ik2o/scala-with-ddd/46

gakuzzzz 2015年2月23日
Dao と Repository の使い分けが気になる……。モチベーション的には同じものですよね Dao と Repository。

taisukeoe 2015年2月23日
各DAOを抽象化して共通インターフェース化したものがRepository、なのかなぁ と思っておりました

todesking 2015年2月23日
エヴァンスDDD6章、リポジトリ - "下層にある技術によって、モデリングの選択肢が制限されることがある" あたりです

tototoshi 2015年2月23日
Repositoryという概念は別にデータソースに依存していないけれど、実際は Repository=Dao になることが多い、って感じじゃないですかね。

gakuzzzz 2015年2月23日
Dao も永続化にDB使うかファイル使うかメモリ使うかなどの実装を隠蔽するための抽象化インターフェイスですよね その辺の認識が異なるのか……？

todesking 2015年2月23日
例えばあるDBでは効率的にクエリできる操作が別のDBではそうではないということが考えられ、それはリポジトリのAPI設計に影響を及ぼさざるをえない

tkawachi 2015年2月23日
http://labs.gree.jp/blog/2013/12/9354/ のコラムではDAOをRDBMSのインターフェイスと捉えてますね

http://labs.gree.jp/blog/2013/12/9354/

そういう意味でのDAOならrepositoryとは違いそう。DAOをrepository的な意味合いで使う場合もありますよね

taisukeoe 2015年2月23日
ソースありがとうございます。確かに思いっきり「例えば、関係データベースを使うと、深い複合オブジェクトの構造に事実上の制限が設けられるかもしれない」って書いてますね あ、「事実上の〜かもしれない」だから理想的にはAPI設計に影響を与えない方が良いが、パフォーマンス上影響を与えざるを得ない場合がある、という理解でいいのかな

todesking 2015年2月23日
6章、「関係データベースに合わせてオブジェクトを設計する」という項があった。 理想的にはインフラを考慮せずドメインモデルを設計したいんだけど、パフォーマンスやO/Rマッピング時のことを考えると妥協は必要だということでしょうね。

taisukeoe 2015年2月23日
あ、すみません「各DAOを抽象化」ではなくDAO以外のデータソース(外部API呼び出しとか）を含めて抽象化したインターフェース、の意でした だからDAO以外のデータソースがない場合は、DAO=Repositoryになる、ということになる…はず

taisukeoe 2015年2月23日

妥協は必要

「実践ドメイン駆動設計」は、このあたりの理想と現実的制約との戦いの話が多めになるのかなぁ。買わねば。

tototoshi 2015年2月23日
なんかinfraとかRepositoryの話になりがちだけどそっちじゃなくて、いにしえよりService層と言われてるようなところの設計をドメインモデルを中心に考えるという話ではないかなあ。で、それはやはりいにしえより続くドメインモデルvsトランザクションスクリプトみたいな話になる。

xuwei-k 2015年2月23日
いにしえとは・・・(哲学

tkawachi 2015年2月23日
みんなDDD本みてて、最初にレイヤードアーキテクチャが来るからその話が人気なのかな(想像

tototoshi 2015年2月23日
レイヤードアーキテクチャが話題に上がるのはフレームワークとぶつかってRailsとか使ってる限り無理だからでは。

gakuzzzz 2015年2月23日

http://labs.gree.jp/blog/2013/12/9354/ のコラムではDAOをRDBMSのインターフェイスと捉えてますね

あーそうこのブログ読んだ時も違和感あったんですよね。このDaoの定義ってどこかに出典あるのでしょうか？ http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm この辺だとRDBMSは実装側だし、Wikipediaもそれっぽい記述ですが出典が見つからず……。

xuwei-k 2015年2月23日
そんなことよりFree Monad勉強しましょう(唐突

todesking 2015年2月23日
DAOの出典はCore J2EE Patternsかなあ(Wikipediaだとそうなってた) http://www.corej2eepatterns.com/DataAccessObject.htm http://www.corej2eepatterns.com/DataAccessObject.htm

gakuzzzz 2015年2月23日
Free Monad で DSL を作ったんですが、こういうDSLの PropertyBased Test を書こうとして止まってしまいました！ どうしたらいいでしょうか！？ おお、ありがとうございます＜ Core J2EE Patterns

You want to provide a uniform data access API for a persistent mechanism to various types of data sources, such as RDBMS, LDAP, OODB, XML repositories, flat files, and so on.

ふむ。

gakuzzzz 2015年2月23日
外部API呼び出しとかを含めて抽象化したインターフェースまさしくDaoっぽい

tototoshi 2015年2月23日
なんかもう Dao でいい気がしてきますね

gakuzzzz 2015年2月23日
Daoだお

kkismd 2015年2月23日
あっ

todesking 2015年2月23日
DaoとRepositoryの違い、Daoはデータストレージの抽象化しか志向していないのに対して、Repositoryはドメインモデルとの接続を強く意識しているというのがあるかな(DDDにおいてDaoパターン使ったら自然にRepositoryになりそう)

tkawachi 2015年2月23日
すみません。それで最初の話にもどるのですが ドメイン層で class MyEntity {...} があって、レポジトリ（インフラ層）で def findMyEntity(id: Id): MyEntity = ??? って書くとしたら、戻り値にドメイン層のクラス出てきてインフラ層がドメイン層に依存してね？って話なんですが これはドメイン層のAPI を定義して trait MyEntityAPI { ... } 、ドメイン層の実装ではAPIを実装 class MyEntity extends MyEntityAPI { ... } 、 レポジトリではファクトリを取る def findMyEntity(id: Id)(factory: ... => MyEntityAPI): MyEntityAPI みたいな形？なんでしょうか？なんか依存は整理できたけど、無駄にごちゃごちゃしたような。

tkawachi 2015年2月23日
何か間違っている気がしてなりません。。。

todesking 2015年2月23日
エヴァンスのDDD本だと具体的なrepositoryの置き場所に言及されてないように見える

ということを考えると、ドメイン層とリポジトリのある層が相互依存することは不可避ではないだろうか

http://stackoverflow.com/questions/18809249

そのものずばりの質問があったけど、どうもしっくりこない……

tkawachi 2015年2月23日
accepted answer みると、ドメイン層はインフラ層に依存すべきではない、と書いてあるなあ。。 class MyEntity と trait RepoAPI { def findMyEntity(id: Id): MyEntity } みたいのがドメイン層で、インフラ層で RepoAPI を実装する感じかあ。

tkawachi 2015年2月23日
onion architecture, hexagonal architecture と DDD本の設計はレイヤー依存関係において異なるみたいですね。 インフラが外か内かという面で。

todesking 2015年2月23日
http://twitter.com/j5ik2o/status/569830145843863552

http://twitter.com/j5ik2o/status/569830775178162176

かとじゅんさんがなぞめいたことを言っておられる

tkawachi 2015年2月23日
導師様ー

j5ik2o 2015年2月23日
ドメイン層はインフラ層に依存していいですよ レイヤー化アーキテクチャーの章読むと良いかと 考えたか色々ありますが、依存は単方向が基本ですね。

j5ik2o 2015年2月23日
いろいろ質問あるようなので、stack overflow などで質問あげると良い気がしますがどうてしょかね？^ ^

2/23はここまででDDDの話題は終了しました。

が、翌日　我々は更にDDDに踏み込む事になります。

残りのまとめも公開しました。(2015/03/06)

Scala界隈でDDDが大いに盛り上がったのでログをまとめましたよ-その2 - Kuchitama Tech Note