今月に入って本格的にDDDを学習中なのですが、対面で増田さんの話を聞いてみたく参加してみました。進捗としては「現場で役立つシステム設計の原則」と「エヴァンス本」共に2〜3割程度を読み終えたところで、まだまだDDD初心者です笑DDD初セミナーでテンション上がってるのでまとめ記事書いてみました。研修概要19時半から21時半のセミナーでした。会場は総武線千駄ヶ谷と代々木駅の間にあるpixiv社でした(社内の環境良くて羨ましかった)概要は以下の通りの2部構成でした。ドメイン駆動設計の正しい歩き方プレゼン資料はこちらです。内容は上記スライドの通りですが、気になった内容は以下の通りです。最近はドメイン駆動設計を試したアウトプットが増えてきたなんでもドメイン駆動設計と照らしてしまっている気がする。設計の一般論だったり、ドメイン駆動設計ではないような内容もあるビジネスがそもそも複雑。システム化すると複雑になる。核心にある複雑さを解くと周辺が自然に明確になる。入出力はフレームワーク等により自然になる核心にフォーカスを当てると全体が綺麗になるので意識的に見た方が良いマイクロサービスでもドメイン駆動設計の言葉が出てきた。コンテキストマップやサブドメインなど開発者がビジネスの活動を継続的に学び続けることが大切。深く洞察していないとどこがコアかわからないチームメンバー全体で行動原理の意識付けが必要パフォーマンス・チューニングで盛り上がった時などに行動原理から外れてしまうことがあるビジネスを多少学んでビジネス用語をある程度使えるようになった時は要注意。ビジネスの複雑さはそんなものではないため、よりビジネスを継続に学び続けることが必要1つのテーブルだけで答えが出るようなものはコアドメインではない。そんなに複雑ではないドメイン駆動のモデルと実装は、どろどろした切り離せないもの実装したら微妙だったからモデルを見直すこともある。モデルと実装は密に結合している技術的に無理やりシステム間を連携させることもできるかもしれないが、シンプルでスマートな方法を常に検討する。考えるか考えないかで出来上がるものが変わる例題の宿泊予約システム料金計算について料金計算については画面もDBも関係ない。domain)モデルを仮に作成し、コーディングする。来なかったらモデルを回収する。モデルを綺麗に作成してそれをコード化するわけではなく往復するコアはスコープ次第で変わる。システム全体か、料金計算の中かで異なるシーズンか特別室か一般室かなど軸は色々試してみる。主軸の選び方を絵だけではなくコーディングまでして確認する。3択あるのであれば3つとも多少書いてみて追っかけやすさなどを確認する歯抜けの仕様書をもらった時に埋められるほどのビジネス知識になったらベスト。POの変更要件に対してどこを修正すべきかがわかるようになると良いドメイン駆動言語に最適なのはJava。Pythonも良いが、Javaが良い。動的な言語だけではわからないことがあるため静的な言語をちゃんとやった方が良い結局現場に導入するには、DDDの体験的な習得が必要。エヴァンス本は即効性はないがジワジワ効いてくる。着目点など、設計の質が変わってくる。読みにくい本なので注意エヴァンス本の読み方コツエヴァンスの読み方としては、体験的に習得し、想定読者条件をクリアしてから読むのが良い2003年ごろのオブジェクト指向モデリングの本は読まない方が良い。顧客クラスや商品クラスといったモデリングはDDD的に意味がない。DBとテーブルをJavaのクラスに当てはめているだけのアプローチであり意味がないオブジェクト指向設計の文書(ワークスブラックのオブジェクトデザイン、バートアンドメイヤーのオブジェクト指向入門(ドンキの2冊)、ラーマンの実践UML)※スペルが間違えているかも「現場で役立つシステム設計の原則」は日本語で翻訳ではなく読みやすい書籍QAビジネスルールを引き出すにはどうしたら良いか。間違えていても仮のビジネスルールを持っていって訂正してもらう。営業はわかっていない。あと、興味ない分野には手を出さない方が良い。モチベーションが上がらない-ドメインマスターが捕まらない場合はどうしたら良いか。DDDにより変更要件を仮実装するハードルが低くなる。痛みがなく暫定的な実装ができるため-なぜビジネスルールは複雑なのか。ビジネスルールの複雑さに立ち向かう」というSlideShareにまとめてある所感ビジネスの活動を継続的に学ぶことは避けられないんだろうなと。フリーランスで対象のシステムが不定期に変化する場合はどうなのだろうか例題として上がった宿泊予約システムの料金計算は大変勉強になった。具体例があるのは本当に助かるモデルと実装を往復する。試しに実装してみるという考えが大切という考えに至らなかった。エヴァンス本は読みにくいと思っていたがやはり読みにくいらしい笑。読み始めのため読み方のコツが聞けて助かったエヴァンス本は紙で買うべきだった。自らの著書「現場で役立つシステム設計の原則」を推していたが、仰る通りエヴァンス本と比較して日本人にわかりやすくて余計なことを書いていない。エヴァンス本より前に読むべき。オブジェクト指向設計の書籍はハードルが高そうだが読まないと。宿泊システムのモデルになった宿の裏設定もあってリアルさに笑った笑。いった背景を理解すると複雑なビジネスロジックになる理由がよくわかる(背景をわかっていないとストレスになるんだなと)。ちなみに「現場で役立つシステム設計の原則」はこちらで紹介されています。会社の開発方法、開発中のシステムに沿った説明でした。具体的な内容が多かったのでプロジェクトの詳細は記載しないようにしておきます。増田さんのエッセンスが入ったDDD開発を実践したモデリングは上流モデリングやRDRAなど様々なレイヤーのモデリングがあるモデル駆動形開発(MDA)。2001年頃から出てきた考え方。した仕様だったりで廃れてきたモデル駆動開発の難点グラフィカルなモデリングは差分が取りにくい振舞は表現しにくいDSLからドメイン層のモデルとドキュメントを作成している。DSLであればクライアントが読める形。言葉が浸透しきった状態。誰も追従してくれないと浸透しない。業種の用語はどう調べるべきか。Webで調べる、実物を頂いて把握するある開発で、言語IDという区分があった。国っぽいものや商品や仕入先っぽいものがあったりした。分ける必要があるかと思ったが、よくよく聞くとクライアントがやりたかったことは、ソートだったり、分けることができないものだった名前から関連を整理するのではなく、実際の意味を理解して関連やオブジェクトの名称を決定するビジネスロジックをドメインのどこに持つかは考えどころ。明細金額を計算するロジックは明細金額に持つか、定価に単価を渡すと取れるか(前者の方を採用したらしい)所感MDA・RDRAなど所見の言葉が多かった。具体的な「あるある」についてはDDDのサンプルプログラムを見て疑問に思った点が出てきたので、悩むべきところに悩んでいたのだなとホッとした笑(具体例は上記メモから端折ったため)実業務にDDDを取り込むとやはりビジネス用語の理解や言語の定義には厳しい目が向けられるみたい。全体所感と今後に活かす点あまり書きすぎても忘れてしまいそう。DDDの学習は書籍だけではダメ、ある程度質の良いDDDシステムに触れる必要があると感じた要点だけでもエヴァンス本をさらっと読む。雰囲気が良くて楽しい研修でした。ME温泉ソムリエエンジニア。サーバ構築からアプリケーションの開発まで手広く対応。