参加背景

今月に入って本格的に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にあるホテル
  • 人材・食材の調達コストが高い
  • 客が入らない場合に販促活動が必要 ちなみに「現場で役立つシステム設計の原則」は

こちらで紹介されています。

第2部 モデル駆動型開発によるビジネスをソフトウェアに落し込む１つのやり方

プレゼンで気になった点

主に会社の開発方法、開発中のシステムに沿った説明でした。わりと具体的な内容が多かったのでプロジェクトの詳細は記載しないようにしておきます。

• 増田さんのエッセンスが入ったDDD開発を実践した
• モデリングは上流モデリングやRDRAなど様々なレイヤーのモデリングがある
• モデル駆動形開発（MDA）。2001年頃から出てきた考え方。フワッとした仕様だったりで廃れてきた
• モデル駆動開発の難点
  • グラフィカルなモデリングは差分が取りにくい
  • 振舞は表現しにくい
• DSLからドメイン層のモデルとドキュメントを作成している。DSLであればクライアントが読める形。
• DDDの用語（コンテキストマップなど）の正確な理解が必要
• ユビキタス言語を作る＝用語集を作る ではない。言葉が浸透しきった状態。誰も追従してくれないと浸透しない。ビジネスエキスパートも含めた対話が必要
• 業種の用語はどう調べるべきか。Webで調べる、実物を頂いて把握する
• ある開発で、言語IDという区分があった。国っぽいものや商品や仕入先っぽいものがあったりした。分ける必要があるかと思ったが、よくよく聞くとクライアントがやりたかったことは、ソートだったり、分けることができないものだった
• 名前から関連を整理するのではなく、実際の意味を理解して関連やオブジェクトの名称を決定する
• ビジネスロジックをドメインのどこに持つかは考えどころ。明細金額を計算するロジックは明細金額に持つか、定価に単価を渡すと取れるか（前者の方を採用したらしい）

所感

• MDA・RDRAなど所見の言葉が多かった。アンテナを張っていなかったな･･･と反省
• 具体的な「あるある」についてはDDDのサンプルプログラムを見て疑問に思った点が出てきたので、悩むべきところに悩んでいたのだなとホッとした笑（具体例は上記メモから端折ったため）
• 実業務にDDDを取り込むとやはりビジネス用語の理解や言語の定義には厳しい目が向けられるみたい。以前の職場でまさにその点が不明確なまま勧めてトラブったので改めて反省

全体所感と今後に活かす点

あまり書きすぎても忘れてしまいそう。とりあえず3つ行動する。

• DDDの学習は書籍だけではダメ、ある程度質の良いDDDシステムに触れる必要があると感じた
• 要点だけでもエヴァンス本をさらっと読む。プログラムに触れてまた本に戻るなどの反復をした方が良さそう
• DDDやってるプロジェクトに参画したい 増田さんがJavaを推してて会場がざわついてたけど、後から調べてみたら主催のビープラウドさんはPython研修等をやっているのね笑
  

雰囲気が良くて楽しい研修でした。また行きたい。

• ← Previous Post
• Next Post →