第一回DDD座談会

都元ダイスケ🍅 @daisuke_m

型ジャンキーｗｗｗｗ #dddzk

まぐろちゃん @saxia

確かに、3ヶ月で死ぬプロダクトにDDDは過剰装備。3ヶ月はがむしゃらに作れは共感できる。 #dddzk

じょいとも @joytomo

原田「プロダクトの最初はやっつけで作って3ヶ月生き残ったらDDDにリファクタするでもいい。」 #dddzk

akinobu nishiyama @ugdark

プロジェクトの遅い理由をDDDのせいにするなら採用するんじゃねぇ。 #dddzk

uzzu @uzzu

採用するっていう聞き方をしちゃったのであれですが、DDDでやるよって口にするもんではないかなと思ってます #dddzk

たかS @takaesu0

てーげーの話中途半端で終わったなorz #dddzk

uzzu @uzzu

これ質問全部終わらなそうw #dddzk

ビオレパパ☆ぃゎ @iwaoRd

次の話題「DDD採用して公開したこと、失敗したこと」 #dddzk

ビオレパパ☆ぃゎ @iwaoRd

ステルス的にプラクティスを組み込むとかは良いけど、DDDやScrumのようにプロセス回す時には周りの人の同意なくして上手くはいかないよね。同意なくしてDDDやりたいから"練習材料にしてます"とかもアレだよねぇ #dddzk

たなかこういち @Tanaka9230

「練習せずにうまくいくわけない」 #dddzk

はむ@フリーランス @secret_hamuhamu

〇〇やってだめだった。 →練習・素振りが足りてない。 完全に同意。 ぶっつけ本番でうまくいくわけ無い。 #dddzk

Toshiki TAKEZAWA👻 @to4iki

ミニマムなサイズで練習しないとって言うのは大概何にでもいえるも思う #dddzk

都元ダイスケ🍅 @daisuke_m

NowBrowsing: DDDで設計するならCQRSの利用を検討すべき - Qiita: qiita.com/ledmonster/ite… #dddzk

凪 @tsubana

練習してからか。。。確かに。。。 #dddzk

uzzu @uzzu

大規模はそもそも練習ができないという問題と、すべての領域に目が行き届かない問題はありそう。小規模から始めて、小規模プロジェクト間の連携を覚えて、なステップを踏んでからなのかなという感じはする #dddzk

Okuda @yoskhdia

大規模な開発でDDDに取り組むのはハードルも高いけれど、効果も大きい。build for change #dddzk

まぐろちゃん @saxia

小さいプロジェクト＝ユビキタス言語で認識統一できる人数でのプロジェクトであればというのはわかる。16人にした時に8人でコンテキスト分したらうまいこといくじゃろってやったら破綻した。 #dddzk

ぺら @Peranikov

少ないメンバーの方がユビキタス言語の認識統一しやすいってこと考えると、大規模開発でもDDDとスクラムを合わせてやるとうまくいくのかな #dddzk

都元ダイスケ🍅 @daisuke_m

これはDDDの話じゃないんだが、麻雀ゲームを作ろうとするとだな。Ton Nan Sha Pei Hak Hatsu Chun というクラスが出来たりして、pon kan cheeとかいうメソッドが生えたりして脳内崩壊する。 #dddzk

焼肉系インフルエンサー @a_suenami

登壇者から指名するという新しさｗ #dddzk

都元ダイスケ🍅 @daisuke_m

麻雀のこと考えてたちゅーねん。 #dddzk

都元ダイスケ🍅 @daisuke_m

OIDCとかmicroserviceを導入すると「ユーザ登録」っていう操作がちょっと特殊になる気がしている。そこを捉えたい。 #dddzk

Okuda @yoskhdia

CQRSのようなアーキテクチャからのアプローチで大規模なシステムと戦うとかもあるかな、と思ったり。集中するところを分けるアプローチ。（勿論、それ以前のところは押さえるとして） #dddzk

uzzu @uzzu

User自体に振る舞いををもたせずcontextに合わせてRollモデル用意して移譲するのはよくやる。そう割り切るとあんまり迷わない #dddzk

kanonji @kanonji

コンテキストをまたがず1個のアプリケーションの中でも、ユーザーエンティティの振る舞いが多くなりすぎて、肥大化するからそれが嫌で、ユーザーをabstractにして役割毎のクラスが継承するのどうかと思ったけど、さすがに実行には移せなかった #dddzk