Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository

Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository

[ozw-sei]

要らないもの作るなって話は同意しかない。でも、Repositoryって集約のファクトリの仲介役でもあると思うんだけど、困らないのかね。その責務を実はどっかに移ってるんじゃないかね。

[Songmu]

完全に同意しかない内容だった

[suthio]

違和感あったのがスッキリした。言語化能力すごい

[ryosuke-fujii]

良い記事。抽象化とレイヤー化は違う

[efcl]

Repositoryの抽象化はどこまでするべきかという話

[i178inaba]

トランザクションとロールバック考慮の部分はわかりつつ、やっぱりアプリケーション層もユニットテストしたい事あるし、その場合は抽象化するほうがやりやすい感じはしてる。(DATA-DOG/go-sqlmockをつかう手もあるのかな？)

[petitviolet]

そもそもこれrepositoryとしておかしいのではというのが気になりすぎて

[Tomato-360]

すごくいい話

[okashoi]

（追記）私の読み違いでした → Repository は（DDDの文脈における）集約の永続化と再構築の装置なので、 スライドにある Transfer みたいなインターフェースは持たない（ドメインモデルが担うもの）という理解。

[yggdra_w]

毎回個別に検討するより、とりあえず Repository にしといて、イレギュラーな実装の時になぜ？って理由が気になって、あートランザクションか、って気付きやすいと思う。

[turanukimaru]

過剰というかむやみやたらな抽象化は不要なのは確かにそう。ただ、この例はトランザクションがリポジトリの外に漏れててアプリが意識しなければならないのが問題であってまずリポジトリの中に閉じ込めるべき。

[masaru_b_cl]

Joelの「漏れのある抽象化の法則」だ

[jonysand]

集約を跨って更新する、というのがそもそも無理が出てくる、という印象。

[mizoguche]

いい話

[otherworld]

可読性のためにインタフェース名には実装の名前を入れようという主張？トランザクション内でHTTPを挟む必要があってそれが致命的ならシステム設計の課題な気も。この主張をするに至った背景や事象がありそう。

[satohu20xx]

あとで

[ono_matope]

E2Eテストは重くなりがちだからアプリケーション層のロジックのテストも適宜ユニットテストによせていきたさはあるなー

[peketamin]

同意。問題のレベルに合わせて抽象化すれば良い、と思ってる。

[kiririmode]

抽象化が必ずしも正とは限らない