PoEAA 9.1章

mtoyoshi @mtoyoshij

皆さんも是非「DI トランザクションスクリプト」とか「トランザクションスクリプトvsドメインロジック」でググッてみて。 RT @chipstar_light: 「DIコンテナがTSとドメインモデルのどちらに向いてるのか」って議論が活発に行われていた事実を今日の輪読で知った。

Takuya Kitamura @chipstar_light

@mtoyoshij 俺はDIコンテナを、オブジェクトの振る舞いを切り替える標準的なインターフェースという理解ぐらいしかしてなくて、大規模開発体制下におけるドメインロジックレイヤに適用する場合はみたいな考えをあまりしてなかったな。

Takuya Kitamura @chipstar_light

@mtoyoshij ただ、「DIコンテナがTSとドメインモデルのどちらに向いてるのか」って議論が活発に行われていた事実を今日の輪読で知った。今ググってみても一杯出てくる。それを見て、ドメインモデルでも利用できなくないけど、TSに利用しやすい仕組みだって事はわかった。なるほどー。

Takuya Kitamura @chipstar_light

「生成できるのはステートレスオブジェクトだけ」というのはあってると思う。生成後にステートフルにする事はもちろんできるけど。　RT @mtoyoshij:...

mtoyoshi @mtoyoshij

もちろん、ステートフルでもいい。俺の前提はDIが生成できるのはステートレスオブジェクトだけという制約があるという理解なんだけど、もしかして違う！？それならかなり嬉しい RT @chipstar_light: 俺は別にDIで生成されるオブジェクトがステートフルでもいい気がするけど。

huskyhead @huskyhead8080

#EAA9_1 （P122）最後の３行がポイントと思った。もっと複雑になったらサービスのロジックが膨らむだけだから設計が破綻していくと。

huskyhead @huskyhead8080

#EAA9_1 サービスは３つの計上方法別に収益計算をしている。

huskyhead @huskyhead8080

#EAA9_1 ゲートウェイはＤＢアクセスでＳＱＬ結果取得。

huskyhead @huskyhead8080

#EAA9_1 （P119）ゲートウェイとサービスで収益計算をしている

huskyhead @huskyhead8080

#EAA9_1 （P118）収入の計上方法が多様な場合の例。ここでは３つの計上方法が例とされている。

huskyhead @huskyhead8080

#EAA9_1 （P117）そんな中でもシンプルなロジックは一部で存在するので、そこにＴＳを利用する（？）

huskyhead @huskyhead8080

#EAA9_1 ドメインモデルがあまり理解できていないから、具体的に比較できないけど。。

huskyhead @huskyhead8080

#EAA9_1 （P117）ＴＳの長所はシンプルさ。ただ複雑なロジックになるとＴＳでは限界があるから、ドメインモデルの構築を検討する。

huskyhead @huskyhead8080

#EAA9_1 （P116）スクリプトを複数にする方法は単純に１つのクラスに処理を纏める場合と、呼び出し方法を統一する為にコマンドパターンにする場合。

huskyhead @huskyhead8080

#EAA9_1 （P116）まずはスクリプトのコード化はそのままやればいい。問題はスクリプトをどこに置くかという事。

huskyhead @huskyhead8080

#EAA9_1 いきなり分かりにくくなったけど何とか頑張ります

ricymst @ricymst

#EAA9_1 このパターンは、1つのトランザクション（ドメインロジック＋SQL）に着目して、手続き型で処理をごりごり書くかんじでいいのかな？

Takuya Kitamura @chipstar_light

#EAA9_1 確かに差し替えたい部分は振る舞いだけど、ドメインモデルでもモデルの振る舞いをかえるためにDIを使うっていうのは妥当な気がするんやけど、どうなんでしょう。

Takuya Kitamura @chipstar_light

そうなんかな？俺は別にDIで生成されるオブジェクトがステートフルでもいい気がするけど。　RT @mtoyoshij: #EA9_1 DIから生成できるオブジェクトはステートレスで、それゆえに生成されるオブジェクトの種類はロジッククラスとなる。

Takuya Kitamura @chipstar_light

#EAA9_1 まぁここで言いたいのは命令をコマンド化する事よりは、スクリプトを定型的なインターフェースで体系化する事が目的のようだけど。

Takuya Kitamura @chipstar_light

バッチプログラムなど、リランが必要なドメインロジックならコマンドパターンがいいのでは？ RT @XY_kyo: #EAA9_1 「トランザクションスクリプトを複数のクラスに体系化する方法は2つある」の中の「コマンドパターン」って使われるのはどういうケースかなぁ…

Takuya Kitamura @chipstar_light

#EAA9_1 うちの会社の開発は、TSでドメインロジックを組んでるね。ドメインモデルで組んでるSIを見た事が無い。手続き型に近いからかな。目の前の実現したい処理を中心に考える傾向があるので。

Takuya Kitamura @chipstar_light

確かにそうだ。　RT @mtoyoshij: #EAA9_1 ロジック抽出の主眼をどこにおくかというのがポイントやね。トランザクションスクリプト（以下、長いのでTS）は処理に主眼をおくパターンやね。ゆえに、とっつきやすい。

河野秀樹 @nangoku_skier

#EAA9_1しかしこのトランザクションスクリプトパターンをパターンとして認識するという発想は正直なかった。パターンに関しては勉強不足を露呈。

河野秀樹 @nangoku_skier

#EAA9_1@XY_kyoコマンドパターンを適用してもうまく解決するのは難しそうな気がする。所詮メインプログラム的なので小規模な場合のみ適用かな。