2019/04/11(土)に行われた「レガシーをぶっつぶせ。現場でDDD！」のまとめです。
ハッシュタグは#genbadeDDDです🐦
私は最初「ジェンベィドDDD…？」となりましたが、正解はこちらでした↓
イベントページはこちら↓
DDDはQuickly版を読んだくらいしか勉強したことがなく、実務に取り入れたことはありません。なのでもし間違っていることを言っていたらご指摘いただけると嬉しいです。
個人的にDDDは「最強の開発手法」だと思っており、勉強したいという思いが強いため、今回参加させていただきました。
開場
- 時間：12:00-
会場はヤフーさんです。
たくさんの方が会場にいらっしゃっています！
DDDに興味のある方がこれだけ集まるとは素晴らしい会です。
趣旨説明、会場の注意事項
- 時間：13:00–13:10
今回の勉強会の目的や、会場の注意事項などを説明されていました。
経産省が公開している「DXレポート」が面白いとのことなので、後ほど読みます。
本日はきれいな理論でなく現場のドロドロ感をご共有いただけるとのことです。実務に役立ちそうで嬉しいです！
あと↓とのことなので、TwitterやこちらのMediumで発信しまくらせていただきました笑
発表
ソフトウェアの核心にある複雑さに立ち向かう
- 時間：13:10–13:50
- 発表者：増田 亨さん(@masuda220)
なぜDDDでつくるのか、複雑さにどう立ち向かうかという発表でした。
増田さんのSlideShareにあがっているスライドはいろいろ読ませていただいたことがあるのですが、発表を聴講するのは初めてだったので「おおー」となりました笑
DDDでつくる理由を2つ紹介されていました。
- 進化と成長を続けるため
- 変更を楽で安全にするため
1つ目はDDDを概念としてみた場合で、2つ目はDDDをアーキテクチャとしてみた場合なのかなと思いました。
ここでいう「概念」とは「ドメインを中心として設計していく手法」のことで、「アーキテクチャ」とは「アグリゲートやリポジトリなどの設計パターン」のことです。
うーん深い言葉です…。当たり前なのかもしれませんが、逆に言えばドメインが単純なら設計が複雑にならないということでしょうか？
発表を最後まで聞いたのですが、「ドメインロジック」と「ビジネスルール」の違いがわかりませんでした…。スライドを読み返したりして精進する必要があると感じました。
「ドメインモデル」など他の用語も同様です↓
こちらはものすごい納得しました。いくら変更が楽になると行っても、変更することに変わりはないですもんね笑
個人的に概念としてのDDDはドメインエキスパートがキモだと思っています。
特定の職種の方向けのシステムを作成していたことがあるのですが、その職種の方が開発に直接携わることがなく、お話を伺いたいときはアポを取って限られた時間内でしか聞けませんでした。
DDDでドメインエキスパートとして社内にその職種を経験したことがある方いたらいいだろうな…と思っていました。
スタートアップの企業には最初からドメインエキスパートはいなく、ビジネスルールを一緒につくっていくとのことです。
私は「ドメインエキスパート=有識者」のような認識でいたのですが、どうやら異なるようです。スライドにも「ドメインエキスパート=ビジネスルールを具体的に知っている人」とありました。理解できていないので、やはりもっと用語を自分の中に落とし込む必要があります。
他の方のツイートも紹介します。
エヴァンス本の読み方についてもお話されていました。まだ読んだことがなく、これから読もうと思っているのでありがたかったです。
とにかく素晴らしいスライドでした。
DDDの用語を理解した上でスライドを読み返したいと思います。
抽象的な教えを試行錯誤しながら解釈したDDDの実践レポート
- ルームB
ここからはルームAとBの2部屋に分かれました。 - 時間：14:00–14:40
- 発表者：ほげさん(@suzuki_hoge)
DDDの特徴？の一つでもある「抽象的な概念」を試行錯誤しながら解釈して実践したお話でした。
全体的にパワーワードが多くてめちゃくちゃ面白かったですｗ
失礼なのかもしれませんが「ほげさん」という名前ですでに面白く、「タジュード」という掴みで会場も爆笑でした。
「ウホーイ」という名前もよく笑われるので、あまり人のことは言えませんがｗ
「ドメインを育てる」というワードは笑ったのですが、他の方の発表でも頻繁に飛び交っていたので、どうやらDDD界隈では当たり前の言葉のようです。
私もドメインを育ててみたいです。
DDDの始め方としては、まず仕様から名詞や動詞を抽出して絵にするとのことです。ここでいう「絵」はPlantUMLなどで作成したクラス図のようなものです。
他の抽象的な概念の解釈はスライドを見た方が伝わりますし、自分自身も理解し切れていないので割愛します。
最後の「目的は脱レガシーだから、何を満たせばDDDなのかはどうでもよくなった」という考えは大事だと思いました。DDDは抽象的で、ひょっとしたら答えのないものかもしれません。
私もそうですが、DDDをやりたいという考えまで行き着く人は完璧な設計を目指しがちだと思います。ただあくまで手段であって目的ではないので、業務としてDDDをやるならどこかで割り切る必要がある、ということだと認識しました。
他の方のツイートも紹介します。
DDDの抽象的な概念の解釈が面白く理解できる素晴らしいスライドでした。
ベンチャーでドメイン駆動設計をやるとどうなるか？〜Pythonで型に倒してみた〜
- ルームB
- 時間：14:50–15:30
- 発表者：安西 剛(ヤスニシ ツヨシ)さん
スライドがあがっているかはわかりませんでした。
Pythonという型なしのスクリプト言語を型に倒してDDDを導入するという発表でした。
初心者向けということでこちらの発表を聴講しました。聴講者は50人以下のベンチャーの方が半分以上でしたが、そうでなくても楽しめる内容でした。むしろ会社の規模よりPythonを知らないと楽しみづらいかもしれません。
まったりした雰囲気をつくってくださり、心地よく聴講することができました。40分×6+50分×1の勉強会で疲弊してくるので、こういったご配慮はありがたいです。
ツイッターに感想などを書き連ねたので、そのまま紹介します。
完全にPythonのお話でしたが、知らなくても楽しめるスライドでした。
劇的ビフォーアフター〜BIGLOBEのDDDの昔と今〜
- ルームB
- 時間：15:40–16:20
- 発表者：曽根 大作さん
スライドがあがっているかはわかりませんでした。
BIGLOBEモバイルの開発においてDDDの導入前後でどのように変わったかというお話でした。
実務の内容を紹介されていたので、とてもためになる発表でした。
最初はXMLベースの独自言語をテキストエディタのみを使って開発していたとのことです。「Javaを導入する」という言葉がここまで頼もしく見えたのは初めてでした笑
「のれん分け方式」については、まずそれを実行できる組織になっているのがすごいと思いました。組織全体がDDDに取り組むという姿勢になっていないと実現できないはずなので、素晴らしい会社だと思いました。
あとはDDDにおけるパワーワード…もとい重要単語が何かも理解してきました。
RDRA(ラドラ)という言葉を初めて聞いたのですが、「Relationship Driven Requirement Analysis(リレーションシップ駆動要件分析)」の略のようです。
DDDの導入前後を具体的に示していて素晴らしいスライドでした。
実録！LOHACOにおけるDDDとCleanなArchitecture
- ルームB
- 時間：16:30–17:10
- 発表者：佐藤 大典さん(@dskst9)、中村 俊之さん
LOHACOの開発でDDD+Clean Architectureを導入したお話でした。
こちらもBIGLOBEモバイル同様、実務の内容を紹介されていて、とてもためになる発表でした。
自己紹介に書かれていましたが、このような考えを持つエンジニアが増えると嬉しいです↓
前半は佐藤さんによる発表でした。
「モノリシック」という言葉を初めて聞きました。「モジュールが分割されていないこと」を指す用語のようです。
この考えは大事だと思いました。やはりDDDは抽象的で難しいので、まずやってみないと具体的な理解はできないです。
アホみたいな感想も載せておきます。
あとはこれなんですよねぇ…。
ECサイトはよく例があるのでわかりやすいのですが、自サービスに置き換えるとわからなくなるという…。
最後の増田さんのお話にもありましたが、日頃からドメイン分析の練習をしたいと思いました。
どの発表でも重複して言っていることが多いと感じました。批判ではなく、行き着く先として伝えたいことが同じということは、それだけ重要だと感じたということです。
こちらも同様です。ドメインモデルの設計から行うことは重要だということです。
これはまさに「ですよね…」でした。「開発当初」は「プロジェクト立ち上げ時」と考えるとレガシーをぶっつぶせなくなるので、「リニューアル開始時」と考えるのがよさそうです。
上記のページを参考として載せられていましたが、全く理解できていないので後で読みます。
後半は中村さんによる発表でした。
中村さんはDDDを始めるにあたり、まず以下の4冊を買って読んだとのことです。
Clean Architecture本だけはLOHACOにないとのことでした笑
この4冊は私も気になっているのですが、どれも読んだことがないので、DDDを始めるときには絶対に読もうと思いました。(正確に言うとClean ArchitectureはDDDと別ですが)
もちろん読み方は増田さんのいうように工夫する必要があります。
Clean Architecture(本でなくアーキテクチャ)については、私が担当しているiOSアプリが「VIPER」というMVP + Clean Architecture + Router(画面遷移(とDI)を担当するモバイルアプリならではの層)のアーキテクチャを採用しているので、理解はしているつもりです。
LOHACOではドメイン層からライブラリを排除するのに徹底していました。Springに詳しくないのでメリットがどの程度なのかはわかりませんが、たとえ実践できなくても最初に「ドメイン層は何にも依存させない」と考えておくことは大事だと思いました。
以下が気になりましたが、質問するタイミングを逃してしまいました…。
LOHACOのアーキテクチャを具体的に説明されており、とても参考になるスライドでした。
ビジネスルールの複雑さに立ち向かう実践技法
- 時間：17:20–18:00
- 発表者：増田 亨さん(@masuda220)
ここからまた部屋が1つにくっつきました。
ビジネスルールに立ち向かう4象限についての発表でした。
難しくて着いていけない部分もあったのですが、こういうことのようです↓
各象限の具体的な内容は増田さんのスライドを見た方が伝わるので、ここでは説明しません。(正確にはまだ理解し切れていないので説明できません)
名言も飛び出しました。
私はC#やSwiftなど型がある言語しか使ったことがないため、今日ほど「型」について考えたことはありませんでした。ただここで増田さんがいう「型」はStringやIntなどではなく、Moneyなどもっと具体化したもののことだとは思います。
他の方のツイートも紹介します。
これは本当に思いました。エンジニアの能力とプレゼンの能力の両方が振り切っているのはもはやチートです笑
本当に最高のスライドでした。チームに展開させていただきます。そして何度も読み返します。
パネルディスカッション&質疑応答&クロージング
- 時間：18:10–19:00
みんなの質問で評価の高いものからピックアップしてディスカッションする時間でした。
完全な文字起こしではなく、私が意訳した部分もあります。予めご了承ください。
社名や名前は伏せましたが、内容から推測できる箇所があるかもしれません…。
Q1. チームメンバーがDDDに興味を持たず、やる気を示さないときはどうメリットを伝えればよい？(8票)
A1.
- 業務委託にDDDをしてもらいたいときは1ヶ月ディスカッションしながら一緒に仕事をした。エンジニア目線でチームをつくる
- DDDをすることを契約書に書くｗ
- パターンは2つ。1つ目はDDDということを言わずにしてもらう。いきなりDDDの話をしても伝わらない
2つ目は業務委託の方を切りまくるｗ
Q2. DDDで開発する際、リリース日程や作業工数をどのように見積もってどのように計画を立てていますか？(7票)
A2.
- DDDは関係なく見積もりは見積もり
Q3. ユビキタス言語の管理ってどうしてますか？ (5票)
A3.
- いろいろなものをどう取り込んでいくか悩んでいる
- 作ったがメンテナンスされていない
→システムとビジネスの中間に入る人がいないと回らなくなる課題がある - リストをつくる気は全くない。明らかに取り違えているところだけこだわる
Q4. 処理速度とのトレードオフはどれくらいありますか？(ゲームなど60〜120FPSとかで導入できるか)(3票)
A4.
- うちは秒間ウン万件をさばいている。必殺技はGO言語ｗ
パフォーマンスを求められるところだけを分割する。他はきれいなDDDを目指している
Q5. コードが多くなりがちですが、テストコード等はどうしていますか？(3票)
A5.
- スクリプト言語で型に倒さない場合、テストはどうしても増える。型に倒す場合は安全だから減る
- 型があるだけでテストが減る。制約でガードしまくって減らしている
- テストコードを書いていない。信念があるわけではなく、テストコードがない時代だったから設計で防ぐのが習慣になっている
こちらの回答も一種の答えですが、どんなシステムでもテストコードを書かなくてもいいと誤解されないために、こちらのツイートを紹介します。
あと私が理解できていないだけかもしれませんが、型に制約を付けているのであれば、型に対して境界値の単体テストなどが必要ではないのでしょうか…？
Q6. Railsでうまくやる方法はありますか？勇気を出してリプレイスした方が良いですか？(3票)
A6.
- PythonなどはType Hintがあるからそこそこやれる。Railsは素晴らしいフレームワークだが、DDDをするのは辛い
- Railsはわからないが、独自言語をJavaにリプレイスしようとしたが失敗して途中でやめたｗ
少しづつ切り出した方が早いと思う
Q7. DDDなくても開発できるじゃんって言われた時のベストな解答は？(コンテキストによりそうだけど…(2票)
A7.
- 今困っていなければ(DDDを)選択する必要はない
- まず仲間がいた。巻き込みやすい人から狙う。2割を巻き込んだらいける
2割を巻き込むことについてはこちらのツイートが参考になりそうです。
ちなみに私はこちらの質問に対してこう思いました。
Q8. ユビキタス言語が浸透しない→ビジネスサイドが同じ意味の別の言葉を使う 何か対策・工夫はあるか？(1票)
A8.
こちらの回答は聞き逃してしまいました…。
以下のツイートに共感できたので紹介します。
そもそもユビキタス言語は「ビジネスサイド側の用語をエンジニアも統一して使うようにする」ものだと思っていました。(認識が違ったらご指摘ください)
私が書いた「エヴァンス本のおすすめの輪読方法が知りたいです！」が取り上げられなかったのは残念でした笑
でも1票入っていたので嬉しかったです！
おわりに
以下のツイートに思いを込めました。
私の素朴な要望も載せておきます。
ホントにDDD難しいんですよー！！
もっともっと勉強せねば…
ちなみに私は担当しているプロジェクトのアーキテクチャにそんな不満はないので、「業務にDDDを取り入れるため」ではなく「単純にDDDを学びたい」ために勉強しています。
手段が目的になっているのでよくない考えかもしれませんが、アーキテクチャや開発手法を学ぶのが好きなので別にいいと思っています！
趣味と同じような感覚かもしれません。
なんか全体的にまとめ記事というよりはポエムみたいになってしまいました。
これはこれで一種の試みということで、Twitterやコメントなど何でもいいのでフィードバックを頂けると嬉しいです。
最後まで読んでいただきありがとうございました！
