実装を書く場合どう書けばいいのか、その一例を考えてみたというお話しです。為、関数型ガチ勢から見た時いろいろ思うところがある可能性は高いです。マサカリお待ちしております。関連の概念については特に説明しないので適当にググってください。実装パターンを考えるにあたり、達成したい要件としては以下の2点。関連の技術詳細への依存が生まれます。実装として以下の様に言及しています。理想は、クライアントから(クライアントの開発者からではないが)内部の働きをすべて隠蔽し、それによってクライアントコードが、データの格納箇所に関わらず同じになることだ。格納と取り出し、および問い合わせの仕組みをカプセル化することが、リポジトリの実装における基本的な機能である。等でも言及、紹介されているのでさらっと流しますが、依存性逆転の原則を適用して、ドメイン層はインタフェースのみ依存する様にするのが良く見るパターンです。例にするとこんな感じ。一見すると上手く分割できた様に見えますが、これにはまだ明らかな問題があります。内で閉じている為、複数のリポジトリをまたがるトランザクションを管理する事ができません。インターフェースを介して、どの様にトランザクション管理をすればよいか、という新たな課題が生まれた訳です。神はトランザクション管理についても以下の様に言及しています。リポジトリはデータベースに対する挿入と削除を行うが通常は何もコミットしない。work)を正しく開始し、コミットするためのコンテキストがある。トランザクション管理は、リポジトリを手を出さないでいる方が単純になる。界隈に存在するライブラリでどの様にするのが実現するのが良いかはまだ見えてません。コードによる冗長性を可能な限り排除しつつも、ドメイン層のインターフェースは永続化の詳細を抽象化したままアプリケーション層からトランザクション管理をする事ができます。コードにするとこんな感じです。共に要件は達成できました。密結合になっている為、アプリケーション層のコードは永続化の詳細から切り離せていません。アプリケーション層からも永続化の詳細から完全に切り離すには、トランザクション管理の抽象レイヤも作ればいいとは思いますが、トランザクションのブロック内だけを見ればインフラ層の永続化詳細から切り離せているので、このレベルで割り切るのもありな気はしてます。さんが定期観測されている関数型ガチ勢的にはアンチパターンな様です。おいしそうな名前だよねとか言っている場合じゃないと実感します。若干ポエムなのでコードレベルに落としこむのが大変。ベースではなく、今ある技術や考え方を使ってシンプルかつエレガントに実現するプラクティスやパターンを共有する必要性を感じる。多用は良くないのは分かっているけど、各レイヤーのグルーとして使うのはアリだと思っている。プログラマの考え方を広げてくれる素晴らしい言語なんか最後の方は無理矢理感がありますが、続編はすごいH本をちゃんと理解した後にまたやるかもしれません。解のないチラシの裏です。プログラマのみなさん、こんにちは。@tlyncはてなブログをはじめよう!tlyncさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。