今月に入って本格的にDDDを学習中なのですが、対面で増田さんの話を聞いてみたく参加してみました。DDD初セミナーでテンション上がってるのでまとめ記事書いてみました。19時半から21時半のセミナーでした。概要は以下の通りの2部構成でした。内容は上記スライドの通りですが、気になった内容は以下の通りです。なんでもドメイン駆動設計と照らしてしまっている気がする。ビジネスがそもそも複雑。システム化すると複雑になる。核心にある複雑さを解くと周辺が自然に明確になる。マイクロサービスでもドメイン駆動設計の言葉が出てきた。開発者がビジネスの活動を継続的に学び続けることが大切。ビジネスを多少学んでビジネス用語をある程度使えるようになった時は要注意。1つのテーブルだけで答えが出るようなものはコアドメインではない。ドメイン駆動のモデルと実装は、どろどろした切り離せないもの実装したら微妙だったからモデルを見直すこともある。技術的に無理やりシステム間を連携させることもできるかもしれないが、シンプルでスマートな方法を常に検討する。料金計算については画面もDBも関係ない。モデルを仮に作成し、コーディングする。来なかったらモデルを回収する。コアはスコープ次第で変わる。シーズンか特別室か一般室かなど軸は色々試してみる。主軸の選び方を絵だけではなくコーディングまでして確認する。歯抜けの仕様書をもらった時に埋められるほどのビジネス知識になったらベスト。ドメイン駆動言語に最適なのはJava。Pythonも良いが、Javaが良い。結局現場に導入するには、DDDの体験的な習得が必要。エヴァンス本は即効性はないがジワジワ効いてくる。着目点など、設計の質が変わってくる。2003年ごろのオブジェクト指向モデリングの本は読まない方が良い。顧客クラスや商品クラスといったモデリングはDDD的に意味がない。ビジネスルールを引き出すにはどうしたら良いか。間違えていても仮のビジネスルールを持っていって訂正してもらう。営業はわかっていない。あと、興味ない分野には手を出さない方が良い。-ドメインマスターが捕まらない場合はどうしたら良いか。DDDにより変更要件を仮実装するハードルが低くなる。-なぜビジネスルールは複雑なのか。ビジネスの活動を継続的に学ぶことは避けられないんだろうなと。例題として上がった宿泊予約システムの料金計算は大変勉強になった。モデルと実装を往復する。試しに実装してみるという考えが大切という考えに至らなかった。エヴァンス本は読みにくいと思っていたがやはり読みにくいらしい笑。エヴァンス本は紙で買うべきだった。自らの著書「現場で役立つシステム設計の原則」を推していたが、仰る通りエヴァンス本と比較して日本人にわかりやすくて余計なことを書いていない。エヴァンス本より前に読むべき。オブジェクト指向設計の書籍はハードルが高そうだが読まないと。宿泊システムのモデルになった宿の裏設定もあってリアルさに笑った笑。いった背景を理解すると複雑なビジネスロジックになる理由がよくわかる(背景をわかっていないとストレスになるんだなと)。こちらで紹介されています。ME温泉ソムリエエンジニア。サーバ構築からアプリケーションの開発まで手広く対応。