講演の中でスライドには書かれていない、口頭での発言を中心にメモしていたのでその内容をまとめました。
(当日体調が良くなく、聴けなかった講演や聴くのがやっとでメモを取る余裕がなかった講演もあり内容は少なめです…)
基調講演 ドメイン駆動設計という設計スタイル (増田 亨さん; @masuda220)
- 今も現場で闘っている中でのこだわりポイントの紹介
- ドメインロジックに振り切っている
- ドメインロジックは独立した関心ごとであり、入出力の関心の途中に登場するものではない
- モジュールで関心の分離
- ドメインオブジェクトは入出力にとって使いやすいとは限らない
- トランザクションスクリプト(入出力)に慣れているとドメインオブジェクトは無駄に見えてしまう
- 2割のビジネスルールでアプリの8割をしめる
- ビジネスルールをちゃんとしていたら残りの2割はテキトーでもいいのでは → これを言うと揉める原因に
- ドメインロジックに焦点を合わせる(スライド16ページ)は、Evans本の1章を見るべし
- 相互に補完するは効率的というよりも効果が出る
- 現場ではドメインロジックはビジネスロジック、ドメイン知識はビジネスルールと言い換える
- 現実のビジネス活動は範囲が広すぎるため、ソフトウェア化する際に制約が必要 → これがビジネスルール
- ビジネスルールを学び続ける (スライド21, 22ページ)
- （いいことしか書いてない）
- 変更容易性の言葉は少し違和感
- 分解しておけば変化に対して絶対にすぐに対応できるかは分からない
- 表現は不整合は、根底は同じでバリエーションが違っただけ
- でも、心理的安全性のためにも論理的に理解したものを書いたほうがいい
- 詳細は自分たちで補完する
- それが誤りであっても、間違っていたということが分かるのでそれも答えになる
- お客さんは良しなにしてくれると思っている
- 画面だけ見せても全体から見るとほんの少ししか見せられていない
- ドメインエキスパート、ユビキタス言語の前に (スライド23ページから)
- ビジネスルールとコード表現 (スライド31ページから)
- Fact, Rule, Goalのどれを重点的に表現するクラスを設計する
- 排他的ではなくFactとGoalを行ったり来たりしつつRuleを内部で使っていくことが多い
- 独自の型（値オブジェクト）の実装パターン (スライド34ページから)
- 値オブジェクト（独自の型）の効果 ([スライド39ページ](https://www.slideshare.net/masuda220/focus-ondomainlogic/39)) - (信頼性が向上する) 独自の型で安定してくることを慣れてない人に理解してもらうまで時間がかかる - (コードの追跡を容易かつ確実にする)対照的にこちらは、IDEの助けもあって即効性がある - 条件分岐で型を表現する ([スライド40ページ](https://www.slideshare.net/masuda220/focus-ondomainlogic/40)) - 条件分岐を列挙型を使ってリファクタリングする - 列挙型にロジックが集まる - (Swiftのenumは表現力が豊かなのでこれは相性が良さそう) - これらの考えが浸透してくると、プロジェクトを進める上で必要な作業一つひとつにビジネスルール(ユビキタス言語?)が登場するようになる35ページからの値オブジェクトは、実践するときにめっちゃ参考になる！
— ほくろん (@hokuron) August 31, 2019
ある種のリファレンスなのでは⁉︎ https://t.co/KZ2qbt6swV
増田さんの講演は、スライド以上に言葉での情報量が多く追いかけるのが大変でした。その分、得られる情報も多く特に値オブジェクトのくだりは発見が多くありました。
また、DDDを知らない人へ伝えることの苦労は避けて通れないこと、根気よく続ければ浸透してくことも聞けてまさに現場でDDDな内容でした。
DDDのモデリングとは何なのか、そしてどうコードに落とすのか (松岡 幸一郎さん; @little_hand_s (Twitter))
- Discord (https://discordapp.com/invite/fBTE9wf)
- 質問するとすごい人からアドバイスがもらえる
- DDD Reference - DomainLanguage.com (http://domainlanguage.com/ddd/reference/)
- Evans本を凝縮して感じ
- 用語の定義を確認するのに有用
- モデリングに決まった方法はない
- ユースケース図とドメインモデル図を紹介
- ドメインモデル図から始めると、どんどん要素が出てくるため、ユースケース図でその範囲を制限する
- ホワイトボードの時間では、モデリングに関する新たな発見がある
- コード化する際はまずは形から入ってみて、ドメインモデル図を改善しながら問題点を潰していく
- セッターは不要になる
- コーディングもモデリングも一回でバッチリはまることはない
- 両方を繰り返し上達していく必要がある
松岡さんの講演は、リアルタイムで募集した質問に回答するQ&Aコーナーがあり、ご本人のブログなどでまとめられています。
「DDDのモデリングとは何なのか、 そしてどうコードに落とすのか」資料 / Q&A
>>松岡さんのヒゲかっこいいですね！ いつから生やされてるんですか？
— 松岡@DDDブログ書いてます (@little_hand_s) September 1, 2019
2015年5月からです。ビズリーチ転職して1ヶ月経って「そろそろいいかな」と思って生やし出してそれ以来です。笑
新卒研修?(記憶が曖昧)で使った題材を元にした内容が中心でした。決まった方法はなく柔軟に色々な方法を実践していくことが理解への近道なんだなと、Q&Aの回答も含めて感じました。そんな環境なことも羨ましい。。
リアルタイムなQ&Aは、ツイッターでよく見る光景を生のライブで見ているような感覚で新鮮でした。
過去の失敗例から再考するモデル駆動設計 (かとじゅんさん; @j5ik2o (Twitter))
過去の失敗例から再考するモデル駆動設計
過去に僕が失敗した代表例から今ならどう設計するか、という観点でお話します。中心になるトピックは以下です - 軽量DDDの功罪 - ドメインモデル貧血症対策 - 集約の境界定義の善し悪し
- 軽量DDDは戦術的パターンだけをつまみ食い
- ユビキタス言語を反映しないドメインモデルを作ると、実装都合の命名になり通訳コストがかかる → 改善活動が必要
- (スライド14ページの図は今後使ってみたい)
- 値オブジェクトの導入 (スライド15ページから)
- Time and Money Code Library
- コレクションの固有型の利点は、mapとかできなこと
- できると本来totalPrice()で意味を持たせられる機会を奪う
- クライアント側で直接map()で同じロジックをできてしまう
- (値型などは、ラップしている元の型のできることを制限する目的もある?)
- 値型のmutatingは内部で何をしているか読みたくなる
- 集約 (スライド21ページから)
- 全てが集約
- ApplicationService(UseCase)にロジックが漏れてしまいドメイン貧血症に
- 結果生合成となり一時的に不整合な状態が続く
- 集約が一つの場合
- 全てが集約である場合の問題点を補う
- UseCaseもシンプルになり余計ドキュメントいらず
- 説明しづらいのはモデルもでかい
- でかいモデルは実装が大きくI/Oも不利に
-
MessageIdsのような識別子の配列を持たせるアプローチ - queryの責務は集約の外側に持っていく
- 全てが集約
- 設計も Fail fast していく
失敗談のパートでは身に覚えのある、もしくはこれから経験するであろうことが先取りできてお得?でした。
また、軽量DDDで旨味を感じられなかった原因がつかめました。増田さんの講演でも感じていましたが、やっぱりユビキタス言語は大事。
終盤の集約に識別子のコレクションを持たせる方法は、おそらくIDDDにもなかったと記憶しているので衝撃的でした。