第２回DDD座談会に参加してきたメモ

第２回DDD座談会

19:00 - 22:10

ddd-zk.connpass.com

ハッシュタグ #dddzk

DDDを実践でやってる人が結構いる

最近のトピック

上坂さん @takashiuesaka

最近はマイクロサービス系の引き合いが多い 境界づけられたコンテキストの話が多い SchooでDDD入門について喋る

増田さん @masuda220

最初はオブジェクト指向の考え方をチームで一緒にするところから オブジェクト指向だけではだめで、分析設計が出来ないと・・・ きれいな答えを早い段階で手に入れたがるが、その必要はない 一番最初のものはだいたい間違っている フィードバックで整理してあとから見つけていく インクリメントな設計でやっていけば良い 経験値を高めることが必要

奥田さん @yoskhdia

株式会社Socket アーキテクト？マネージャ？ 落ち葉拾い症候群

かとじゅんさん

最近はICONIX大好き 分析をすっ飛ばして戦略の話をしたがる人が多い DDDの面白いところは分析のところ ICONIXはDDDにかなり効果がでている（セプテーニさんで一緒にやっているらしい） 最近のトピックはコンコース

—

成功事例について

DDDの本のやり方とかくらいしかない モデルを深化させて作った事例があまりないように感じるのになぜ多くの人がDDDを議論しているのか ソフトウェアの複雑さはドメインにあるとみんな思っているからではないか うまく行ってる人たちってほんとにいるの？ 本で言われていることはほんとに有効なのか

• DDDで失敗してきた 顧客を巻き込めていなかった ビジネスパートナーとの連携を無視してしまった 政治的な文脈

戦術的なところで役に立ったことはあった（ヘキサゴナルアーキテクチャが威力を発揮したことはあったが、DDDのメインではない

DDDはカオスの辺縁（？聞き取れなかった）をもとめる作業 ユビキタス言語は目標 本人たちにも成功かどうかがわからないから成功事例が出てこないのではないか

@masuda220 成功事例が出てこないのは外から観察できないから 仕事が楽になる、楽しいようにするためにやっている やってよかったと思っている 話のシェアがみんなの財産になる 常に失敗だと思っている

@上坂さん ドメインに注力しているとお客さん的に外に出せない DDDをやろうとしている人たちはストイックで、ずっと追い求め続けてしまっている → 終われない

昔ながらのオブジェクト指向にくらべてDDDがいいのは戦略面的に優れている 経営者からしたらコアドメインは「金のなる木」 エンジニアサイドとビジネスサイドがユビキタス言語で一緒に考えられるのがいいところ

ドメインとビジネスが紐付いてこない サポートが必要

ICONIXとDDDは補完関係

性能がKPIにインパクトに与えるのであればDDDは必要ない

非機能要件もドメインと言えるのではないか @羽生田さん

WEB業界は比較的エンジニアサイドとビジネスサイドはユビキタス言語に近いもので喋れている

DDDの人はドメインによりすぎているイメージがある

シュレイヤメラン？

エヴァンスのこだわるドメイン 一般論としてのドメインを言いたいのではない ビジネスの人がテクニカルなことを言って良い 非機能要件なこともドメインに含めてもよい エンジニアだけでなくビジネスをやってる人間も含めて、開発においてどのくらいの時間、コストを掛けてやるのかを議論する ↑たしかに！

エヴァンスは実際に自分が経験したことのみを書いているだけ

問題領域をエンジニア、ビジネスサイドで議論することを追い求めている 問題領域はテクニカルなところではない

ドメインと境界づけられたコンテキストの違いって？ ドメイン: 問題領域全体 境界づけられたコンテキスト: 解決すべき問題領域

— 豆蔵宣伝 —

InfoQは豆蔵が運営してる InfoQ Japan翻訳者募集中

— 豆蔵宣伝 —

セプテーニ　下村さん ツイート禁止

ユースケース駆動開発でドメインモデル（ユビキタス言語）を抽出（蒸留）

ユースケースを書いてみるとドメインモデル上にない言葉が出て来る

ユーザー、グループがメインだ！というふうに言っていても、ユースケースを声に出して見ると実はパーミッションが・・・とか出て来る

エンジニアの日本語力・・・

集約の話

ドメイン駆動設計のサンプルを見るのがよい エヴァンスはDBのトランザクションの話はしていない ロジックの置き場所としての集約の設計とDBのトランザクションの集約は別物として考えなければならない どこまでのロジックの置き場所かがドメイン駆動設計における集約

Write/Readの集約（ドメインモデル）は別物 @masuda220 集約単位でモデルが存在 Request Modelは集約にニアリーイコール Response Modelはそうではない可能性もある

応募者と求人企業 仕事という概念はそれぞれ違うものがある 求職者ドメイン企業側ドメインと分けてみたこともある @masuda220 アクターの捉え方によって概念は違う

関数型言語でもモデル駆動設計は実践可能か

言語によるものではない やりやすさやりにくさはあるとは思う 関数型は実社会で使うにおいて成熟しきっていない

純粋関数型だと・・・ ↑型クラスを自分で実装すれば良いのでは？ @かとじゅんさん

オブジェクト指向は国語 関数型は数学

国語と数学を分けるのは何か？ 国語は人によって捉え方が異なる 数学は一次曲線のように数式になっていたら誤解がない

エリックがQCON（2011年で来日した時に話を聞いたら、clojureを利用していた DDDが出来るかどうかはわからないと言っていた

どの言語を使うかはチームの話 Javaを使いたいチームであればScalaを選ぶ必要はない

プログラム勉強するならJavaよりHaskellがよさそう

Scalaはマルチパラダイムでいろいろな書き方が出来てしまうので難しい だれかがルールブックになって制御しないといけない

メソッドにユビキタス言語を用いる

オブジェクト指向はT（クラス）に従属 関数型はF（メソッド）に従属

年齢計算とかのFより、年齢とか誕生日のTが先に見つかる

大多数はFが先に見つかるのかも マクドナルドでバイトするという大きなF Fはマニュアル

要求の捉え方

T従属の発想は現実に近い

正しいTとFは見つからない リファクタリングをするときにTのほうが楽だ @masuda220

エリック・エヴァンスのドメイン駆動設計

実践ドメイン駆動設計

ユースケース駆動開発実践ガイド