PoEAA２章

mtoyoshi @mtoyoshij

#EAA3 昔からやってるのもあるし、やっぱ一番きれいにできると思うのでドメインモデル派やな。けど原理主義者ではないつもり。というのもドメインモデルは名詞抽出とかである程度くくり出せるけど、UCの部分はそのままサービスレイヤとして実装するのが自然だと思います。

Takuya Kitamura @chipstar_light

これは俺も同じ意見。理解しやすいよね。 RT @mtoyoshij: #EAA3 ドメインモデルは名詞抽出とかである程度くくり出せるけど、UCの部分はそのままサービスレイヤとして実装するのが自然だと思います。

mtoyoshi @mtoyoshij

#EAA3 ドメインモデルはある責務に特化したクラスになっているので、ある程度小粒な単位のもののはず。オーケストラでいう指揮者的なクラスが個々のクラスを使いながら一つのユースケースを完成させるっていうのが一番バランスが取れてそうな気がします。

Takuya Kitamura @chipstar_light

#EAA2 自分がEA向けのSIに取り組むとしたら、どれを使うってポリシーはないな～。趣味でプログラミングするならドメインモデル派ですが。

Takuya Kitamura @chipstar_light

#EAA2 「直接的手続きではなく、テーブルを中心にドメインロジックを構築することで、構造がわかりやすく、重複の発見と除去が容易になる」と。テーブルモジュールの特徴としてとてもわかりやすい。

Takuya Kitamura @chipstar_light

#EAA2 「３つのパターンは相互に排他的な選択肢ではない」-なるほどー。本にあるようにサービスレイヤとかはそうだよね。

Takuya Kitamura @chipstar_light

#EAA2 「唯一の例外は、行データゲートウェイとともにトランザクションスクリプトを使用する設計から始めた場合である」のところの意味がしっかり理解できなかった。

mtoyoshi @mtoyoshij

コントローラ・エンティティは好きじゃない。なぜなら重複を生みやすいから（続く） RT @chipstar_light: #EAA2 「唯一の例外は、行データゲートウェイとともにトランザクションスクリプトを使用する設計から始めた場合である」のところの意味がしっかり理解できなかった。

mtoyoshi @mtoyoshij

#EAA2 しかし、TSだったものをリファクタリングによって重複を排除するようにした結果、アクティブレコードによるドメインモデルに昇華されていく事がある。これは結果的にはコントローラ・エンティティの形になっており、（続く）

mtoyoshi @mtoyoshij

#EAA2 それなら、重複が排除されているので唯一例外的にアリだと思う。と言っているのだと理解した。つまり、最初からコントローラ・エンティティで臨むとトランザクションスクリプトとドメインモデルの出来損ないみたいになりやすいぞ、と言っているんだろう。ま、これは心当たりありです。

huskyhead @huskyhead8080

#EAA2 「ドメインモデルを熟知したプロジェクトチームなら、初期コストはかからない」逆に言うと、それだけ熟練（パラダイムシフト）が必要。それが大変

Takuya Kitamura @chipstar_light

#EAA2 ドメインロジックを構築するための３つのパターンを選択するには、「初期の要求分析を行える熟練した人に判定してもらわなければならない」か。。。厳しいな～

huskyhead @huskyhead8080

#EAA2 どのモデルを選択するかは、P32のグラフの分岐点が、システムの複雑性を基に、経験的に分かる人って事で。。。現場経験を多く積んだら見えてくるのかな

kyoinn3 @XY_kyo

#EAA2 　結局そういうことでようね、　いろいろ経験を積まないと、経験者にとって当たり前のことは初心者になかなか伝わらないこともあるでようね RT@izumin8080 #EAA2 どのモデルを選択するかは、P32のグラフの分岐点が、システムの複雑性を基に、経験

kyoinn3 @XY_kyo

#EAA2 P32の図は複雑性が7.42を超えるとドメインモデルを仕様すべきとかいてあるけど、その7.42はどういうふうに算出されたか興味津々

ricymst @ricymst

#EAA2 ドメインロジック構築パターンの概要は理解できた。が、本にも書かれているとおり、アプリケーションの特性に合わせて、これらパターンを使い分けたり、また、組み合わせたりすることには、とてもハードルの高さを感じる。