Somurie Engineer's Blog

参加背景 今月に入って本格的にDDDを学習中なのですが、対面で増田さんの話を聞いてみたく参加してみました。 進捗としては「現場で役立つシステム設計の原則」と「エヴァンス本」共に2〜3割程度を読み終えたところで、まだまだDDD初心者です笑 DDD初セミナーでテンション上がってるのでまとめ記事書いてみました。 研修概要 19時半から21時半のセミナーでした。会場は総武線千駄ヶ谷と代々木駅の間にあるpixiv社でした（社内の環境良くて羨ましかった） 概要は以下の通りの2部構成でした。 セミナーページ 第1部 ドメイン駆動設計の正しい歩き方～どこに焦点をあわせ、どう実践するか　増田亨 氏 第2部 モデル駆動型開発によるビジネスをソフトウェアに落し込む１つのやり方　株式会社アクティア 高崎健太郎 氏 （ちなみに会場は満員御礼のようでした！すごい人気！） 第1部 ドメイン駆動設計の正しい歩き方 プレゼン資料は こちらです。 プレゼンで気になった点 内容は上記スライドの通りですが、気になった内容は以下の通りです。 最近はドメイン駆動設計を試したアウトプットが増えてきた なんでもドメイン駆動設計と照らしてしまっている気がする。設計の一般論だったり、ドメイン駆動設計ではないような内容もある ビジネスがそもそも複雑。システム化すると複雑になる。ビジネスの複雑さが根本原因 核心にある複雑さを解くと周辺が自然に明確になる。入出力はフレームワーク等により自然になる 核心にフォーカスを当てると全体が綺麗になるので意識的に見た方が良い マイクロサービスでもドメイン駆動設計の言葉が出てきた。コンテキストマップやサブドメインなど 開発者がビジネスの活動を継続的に学び続けることが大切。深く洞察していないとどこがコアかわからない チームメンバー全体で行動原理の意識付けが必要 パフォーマンス・チューニングで盛り上がった時などに行動原理から外れてしまうことがある ビジネスを多少学んでビジネス用語をある程度使えるようになった時は要注意。ビジネスの複雑さはそんなものではないため、よりビジネスを継続に学び続けることが必要 1つのテーブルだけで答えが出るようなものはコアドメインではない。そんなに複雑ではない ドメイン駆動のモデルと実装は、どろどろした切り離せないもの実装したら微妙だったからモデルを見直すこともある。モデルと実装は密に結合している 技術的に無理やりシステム間を連携させることもできるかもしれないが、シンプルでスマートな方法を常に検討する。考えるか考えないかで出来上がるものが変わる 例題の宿泊予約システム料金計算について 料金計算については画面もDBも関係ない。ドメイン層として独立させる（ドメイン層だけで開発してテストできる）（ドメインを隔離するの原題はisolating the domain） モデルを仮に作成し、コーディングする。しっくり来なかったらモデルを回収する。モデルを綺麗に作成してそれをコード化するわけではなく往復する コアはスコープ次第で変わる。システム全体か、料金計算の中かで異なる シーズンか特別室か一般室かなど軸は色々試してみる。主軸の選び方を絵だけではなくコーディングまでして確認する。3択あるのであれば3つとも多少書いてみて追っかけやすさなどを確認する 歯抜けの仕様書をもらった時に埋められるほどのビジネス知識になったらベスト。POの変更要件に対してどこを修正すべきかがわかるようになると良い ドメイン駆動言語に最適なのはJava。Pythonも良いが、Javaが良い。動的な言語だけではわからないことがあるため静的な言語をちゃんとやった方が良い 結局現場に導入するには、DDDの体験的な習得が必要。エヴァンス本は即効性はないがジワジワ効いてくる。着目点など、設計の質が変わってくる。読みにくい本なので注意 エヴァンス本の読み方コツ エヴァンスの読み方としては、体験的に習得し、想定読者条件をクリアしてから読むのが良い 2003年ごろのオブジェクト指向モデリングの本は読まない方が良い。顧客クラスや商品クラスといったモデリングはDDD的に意味がない。DBとテーブルをJavaのクラスに当てはめているだけのアプローチであり意味がない オブジェクト指向設計の文書（ワークスブラックのオブジェクトデザイン、バートアンドメイヤーのオブジェクト指向入門（ドンキの2冊）、ラーマンの実践UML）※スペルが間違えているかも 「現場で役立つシステム設計の原則」は日本語で翻訳ではなく読みやすい書籍 QA ビジネスルールを引き出すにはどうしたら良いか。間違えていても仮のビジネスルールを持っていって訂正してもらう。営業はわかっていない。あと、興味ない分野には手を出さない方が良い。モチベーションが上がらない -ドメインマスターが捕まらない場合はどうしたら良いか。 DDDにより変更要件を仮実装するハードルが低くなる。痛みがなく暫定的な実装ができるため -なぜビジネスルールは複雑なのか。「 ビジネスルールの複雑さに立ち向かう」というSlideShareにまとめてある 所感 ビジネスの活動を継続的に学ぶことは避けられないんだろうなと。フリーランスで対象のシステムが不定期に変化する場合はどうなのだろうか 例題として上がった宿泊予約システムの料金計算は大変勉強になった。具体例があるのは本当に助かる モデルと実装を往復する。試しに実装してみるという考えが大切という考えに至らなかった。目からうろこ。 エヴァンス本は読みにくいと思っていたがやはり読みにくいらしい笑。まだ読み始めのため読み方のコツが聞けて助かった エヴァンス本は紙で買うべきだった。Kindleで読みにくい･･･ 自らの著書「現場で役立つシステム設計の原則」を推していたが、仰る通りエヴァンス本と比較して日本人にわかりやすくて余計なことを書いていない。エヴァンス本より前に読むべき。 オブジェクト指向設計の書籍はハードルが高そうだが読まないと。。 宿泊システムのモデルになった宿の裏設定もあってリアルさに笑った笑。こういった背景を理解すると複雑なビジネスロジックになる理由がよくわかる（背景をわかっていないとストレスになるんだなと）。 ちなみに宿の裏設定は以下のようなもの 標高2000mにあるホテル 人材・食材の調達コストが高い 客が入らない場合に販促活動が必要 ちなみに「現場で役立つシステム設計の原則」は こちらで紹介されています。