Richard Imaoka's Blog

Scalaプログラマ兼Explainer Video作家、リチャード・伊真岡のブログです。マーベリック株式会社で技術広報として働いています。

レガシーをぶっつぶせ。現場でDDD!に行って聞いたトークごとの感想

こちらのイベントに行ってきたので感想を書きます。

genbade-ddd.connpass.com

登壇者、主催者には参加者からのフィードバックがたぶん一番嬉しくて、次回開催のモチベーションにもつながるのでみなさんもブログを書くととても喜ばれますし、ブログが大変ならツイッターでも伝えるとすごく良いと思います。わたしも勉強会の手伝いをやったことがあるのでその辺はわかります。

ソフトウェアの核心にある複雑さに立ち向かう 株式会社ギルドワークス 増田 亨

初めて増田さんを直接みてお話を聞きました。サンプルコードが出てこない抽象度の高い内容の発表だったのに、参加者に「それそれ!」と思わせるトークはさすがだと思います。基本的には増田さんの著書の内容の復習みたいなものだと思いますが、著者本人がライブで強調する部分、例えば型を使うことの効用を説くのを見られるのは伝わり方が違う、本を読むだけとはまた違うなと感じました。増田さんの本を読んでない参加者も多かったと思われるので、そういう人たちには良い導入になったでしょう。

www.slideshare.net

レガシーシステムからモダンな環境への移行 ~Y!プレミアム・バックエンドシステムのリニューアル~ ヤフー株式会社 清水 将貴

Y!プレミアムの会員数がすごくて、ソフトバンクユーザーが自動的に無料でY!プレミアム会員になっている分を差し引いても、エグい金額稼いどるなーとか考えながらトークを聞いていました。

レガシーなシステムがアドオンに次ぐアドオンで膨張していったり、新規処理フローから既存の処理フローを内部的に呼び出す形で実装することで既存フローを活かしつつ既存フローの破壊を防いだりなど、私もレガシーなシステムの多い証券会社で働いていたので身につまされる話が多かったですね。

欲を言えばもうすこし具体的に「この変更をやったらココがぶっ壊れて、こんな影響が出て、だから以前の実装はまずかったよね」みたいな臨場感のある話、障害例や失敗例を聞きたかったけど外に出せない話も多いのでしょう。

登壇者の清水さんには私から質問をして「レガシーコードをある程度までリファクタリングしてからDDDでの再設計を本格化しましたか?それともレガシーコードはだいたい放っておいてDDD再設計にとりかかりましたか?」という質問に「後者です」と答えていただきました。ありがとうございました。

ちなみに私は前者のアプローチでDDDの導入を試みて失敗しています。(先程の証券会社をやめたあとの別の会社)レガシーシステムを開発したメンバーが抜けてしまった後だったので、知識の醸成のためレガシーリファクタリングをしながら業務を学びゆっくり頑張ろうと思っていたら先に会社の方がなくなってしまったのです。(正確には会社は精算して事業は別会社に譲渡)

DDDサンプルコード ライブリファクタリング 関西Javaエンジニアの会 irof 株式会社ギルドワークス 増田 亨

irofさんのコードを書くスピードが非常に早く40分間でもガシガシ進捗が出る、まさにライブ感のある面白いセッションでした。なにより「なれた人がSpringBootを使って実際にリファクタリングを行う手順」を見られたのが大きいです。現場でDDDをベースにした議論とコーディングのイメージが湧いた人も多かったのではないだろうかと思います。わたしはSpringBoot使ったことない分、そのあたりがとても勉強になりましたね。

コードが公開してあるのも素晴らしい、後で見たいです。本当に本当にありがたい。

github.com

セッションの中でクラス間の関係をダイアグラムであらわすJigというツールを使っていたけど、これもirofさんが書いてたのか…すごいな。

github.com

劇的ビフォーアフターBIGLOBEのDDDの昔と今〜 ビッグローブ株式会社 曽根 大作

個人的にすごく良いと思ったセッションでした!BeforeとAfterを対比させることで以前の問題点とDDD適用後の改善点が対比されわかりやすいく、DDD本によくある施策具体的にやってみたらどうなのよ?という疑問に対する回答例を与えてくれたと思います。そしてDDD適用後もまだ疑問や課題が残っていることを示してくれたことが教科書的でなく生きた実例としてさらに学びがありました。

あと概念図、なんとか図(名前忘れた)と3段階くらいにDDDで使う図を分けるのも「それそれ!そういうのが知りたかった!」と個人的ヒザパッシーンの瞬間でした。自称図解大好きマンの私としては、多くの人がすぐ一枚の図に情報詰め込みすぎるのを苦々しくおもっていたので、こういう図を分けて複数使うプラクティスが実践されて紹介されるのは大いに学びがあります。

実録!LOHACOにおけるDDDとCleanなArchitecture アスクル株式会社 佐藤 大典、中村 俊之

軽量DDDや一周戻ってきてサブドメインを統合すべきじゃない?という話など、チームみんなで学びながらDDDを実践している様子がわかる良いセッションだったと思います。個人的には「DDD本の境界づけられたコンテキストの図がわからん」の話がツボでした。いや、あれは確かにわからない笑。

ビジネスルールの複雑さに立ち向かう実践技法 株式会社ギルドワークス 増田 亨

朝の増田さんの発表の続き。途中アメリカの大学でのマーケティングの授業っぽい話が出てきたけど、業務を理解するというのはそういう一面もあるのかなと思いました。携帯電話会社の料金プランからDDDモデリングをやってみるというのはいい練習になりそうですね。世の中お金に関するルールは複雑になりがちで、多分みんな余計なお金は一円でも払いたくないし反対にお客さんを獲得するにはいろんな創造性に富む(笑)方法で金を突っ込むからかなーと思うのですが、そういうところはDDDの効果が大きい領域なんでしょうね。

www.slideshare.net

パネルディスカッション&質疑応答&クロージング

さすがにこの時間になると疲れてきたので、主催者や登壇者はその何倍も疲れているだろうから大変だなーと感心しながら聞いていました。質問で印象的だったのは「ゲームなど速度の要求される領域でもDDDは使えるのか?」というものですが、

  • 「DDDでレスポンスの速度を出すために工夫やトレードオフを検討した経験はあるか?」
  • 「ゲームを始めとする速度を要求される場面でパネリストがDDDを使ったことがあれば、その経験を聞きたい」

という質問に変えてみたらもう少しわかりやすかったのかなと思います。個人的にはこのあたりはDDDとは関係なくて、だからDDDをやりながらでもできる話で、結局はパフォーマンス要求水準を決めて、ベンチマークをやって、プロトタイプ作りつつ計測を重ねていくという方法しかないと思っています。そのあたりの実践については樽八さんの本、

背景理論についてはBrendan Greggさんの本やWebサイトが一番のリソースですね。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

www.brendangregg.com

最後に

主催者の皆様、登壇者の皆様、非常に良いイベントを実現してくださってありがとうございました。レガシーをぶっつぶせ!といいつつも、現実世界ではレガシーのほうが開発者をぶっつぶそうとしてくるので、そんな力に抗うまさに「ドロドロした」現場感の溢れるセッションが多かったと思います。私はレガシーにぶっつぶされた開発者として(笑)登壇者のみなさんの勇敢な取り組みを心強く思い、いつか仕事でDDDを使うときのため腕を磨いていこうと思います。