[ドメインモデルをピュアに保ちたくない人現る]本日のDDD界隈

nunulk(decayed) @nunulk

うーむ、やはりドメインモデルはフレームワークから離した方がいいんだろうか…静的解析かけてもノイズがひどくてストレスフル

白い高野さん @masaru_b_cl

@shinpei0213 ではドメインモデルの設計について

白い高野さん @masaru_b_cl

モデルへのDIをどうやってるとか、どういう切り口でDIしてるとか

白い高野さん @masaru_b_cl

完全に間に合わない無茶ぶりだ

増田 亨 @masuda220

オブジェクト指向の開発単位は対象領域の切れ目で分割する。分析・設計・実装の作業種類で分割しない。分析クラス＝実装クラスになるように三つの活動を境目なくひとつのチームが担当する。モジュールをデータと機能で分けない。データとロジックをいっしょにしたクラスをモジュール単位にする。

増田 亨 @masuda220

対象領域の境目の二つの見つけ方。一つは情報やデータの関係性の強さに注目して、関心事の対象の輪郭をはっきりさせる。もう一つは、業務の進め方のバリエーションに注目する。一見、同じような業務の流れで、相手や商品の種類で異なる業務ルールを適用する業務シナリオのバリエーションを見つける。

増田 亨 @masuda220

三層＋ドメインモデルの構造は、業務ロジックの記述の重複をなくす工夫。アプリケーション層は似たような機能（サービスクラス）の変形版が重複することもあるけど、判断／加工／計算などロジックの実体は、ドメイン層のオブジェクトに一元的に記述できる。多様性に対応しつつ、共通化も進む。

増田 亨 @masuda220

ドメインモデルをデータクラスの集合にしちゃうと、ロジックはアプリケーション層に集まり、同じロジックがあちこちに重複する。ロジックを（オブジェクトではなく）関数単位のライブラリでの共通化は、適切なロジックの置き場所の整理の軸が見つけにくい。結局、ロジックの整理と共通化に失敗する。

rei_m @rei_m

すごい良記事だと思うんだけど、コメントのとこのMVWの流れの中でDDDが同列に並ぶのは違和感があるような？ / 他4コメント b.hatena.ne.jp/entry/qiita.co… “iOSアプリ設計大全集 2016 - Qiita” htn.to/z2zB3

Keita Kagurazaka @kkagurazaka

@rei_m 戦術的DDDを指してる気がしますね

rei_m @rei_m

@kkagurazaka 戦術的DDDってドメインをコードに落とし込む上でのテクニカルなパターン（VOとかエンティティとかリポジトリとか）のことでMVWのM層に閉じた話かと思ってたんですけど、全体を指す感じなのですかね？

Keita Kagurazaka @kkagurazaka

@rei_m フォーカスされてるのはモデルだと思いますが、DDD本でも4層アーキテクチャに言及があったりするので、ドメインモデルをうまく扱うための全体像についても一応戦術的DDDの範疇なのかなと。僕の個人的なイメージですが。

rei_m @rei_m

@kkagurazaka そういう捉え方も確かに考えられますね。なるほどです。

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

エンジニアにとって大切なもの：エンジニアリングに対する真摯な姿勢

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

ドメインレイヤーのクラス群は外部の道具を使っちゃダメ、ピュアにしろ！ってのは、割りと昔から私には納得できない話の1つだ。私は、ドメインモデルを表現するために積極的・明示的に道具を使う。それが普通だと思うし、おかしいとは思えない。

Hidenori Goto | COO and CTO at KabuK Style @hidenorigoto

昨日の勉強宴会での話を振り返って1つ自分への反省として気づいたのは、自分が思考のクセとして対象物や対象物の意味的構造の方を重視したがるということだ。このクセから敢えて離れるチャレンジが必要と感じた。

r.ishibashi @cactaceae

@hidenorigoto @sugimoto_kei 道具の中身をちゃんと理解するのが大変で理解度によってドメイン自体の解釈が変わってくるようになっちゃいません？

杉本啓 @sugimoto_kei

自分が使う道具はよく理解しないといけませんよね。でも、道具をよく理解したことによりドメイン理解が深くなる、という面もあるかもしれません。道具に依存しないピュアなドメイン理解、ってあるのですかね。言語だって道具なので。 twitter.com/hidenorigoto/s…

がくぞ @gakuzzzz

ドメインロジック上でLensを使う機会に今のところ会ってないんだけど、ピタリ嵌る場合ってどんなのかな？モデルの深い層に直接外部から触るのはカプセル化～という感じだし。Property-Basedテストでランダムに生成したモデルの一部をテストに合わせて変更したい時とかには使ってる

杉本啓 @sugimoto_kei

ソフトウェアビジネスでは、商品性の設計が一番難しい。どんな潜在顧客のどんな欲求を対象とするか。競合製品と比較してどんな訴求ポイントを組み込むか。どんな価格付けでどの程度の量を売るのか。サービスとどう組み合わせるのか。そうしたことは意図的にデザインされなければならない。

杉本啓 @sugimoto_kei

プログラミングの先にドメインモデリングのような世界があるという言説はプログラマの耳に心地よい。プログラミング経験はドメインモデリングに役立つが、それだけでは十分でないと僕は思う。プログラム以外のこともやらなければ、よいモデルは作れない。そういうことを誤魔化してはいけない。

r.ishibashi @cactaceae

色んな意見があって良いし違う意見の人は、何か僕とは違うものをイメージしてるような気がしてるんだけど、道具に寄りかかってるドメインモデルというのは自分のドメインを抽出できてない可能性があると思う。

r.ishibashi @cactaceae

道具を使ってやりたい事があるとすると、やりたい事と道具の使って実現する手法と道具の使い方の３つくらいには関心ごとが分離できて、やりたい事の部分がドメインになるはず。

r.ishibashi @cactaceae

本当に道具に密接に関わってて分離できないとしたら、その道具を拡張なり改良なりするべきなんじゃないのかなぁ。

r.ishibashi @cactaceae

あと実装寄りの話になるけど、ドメインに外部の道具が入ってると、ユニットテストが書きにくい。モックするか、道具の挙動まで含めてテストするするはずだけど、モックは必要悪で使わなくて済むように実装できるならそうするべき。後者は言わずもがな。