はじめに

BIGLOBEで開かれた、
「レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡」というイベントに参加してきました。
実はDDDの知識はほぼゼロで、
ただ「レガシーなコードをイケてるコードに書き換えたメソッドを知りたい」と思い勢いで申し込みました。
仕事、プライベートともに忙しくだいぶ遅くなってしまいましたが、
個人的に響いたところ（だけ！）を記事にしてみます。
登壇者の方々の資料はすべて公開されていますので、
内容が気になった方はぜひ実際の資料をご覧いただければと思います。



コンテンツ

BIGLOBEにおける、5年間のDDDの取組と今後について

登壇者：西秀和さん
資料：DDD Alliance レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡

大規模でレガシーでメンテナンス性の低いソースコードを、
スクラム開発とドメイン駆動設計で刷新している途中とのこと。

  • API/バッチ6500本（大規模）
  • 複数の企業/チームに外注
  • 独自言語
  • viで編集
  • 手動テスト
  • LinuxなのにWin

というなかなかのおっかなさには会場に笑い（失笑？）が。

そんな中で挙がった問題点が、

  • 機能追加、変更の影響調査に時間がかかる
  • 詳細設計は末端の開発者しかわからない

という2点。
状況は全く違いますが、私のところとも通じる問題点だなと思いました。

その打開策として行ったのが2点。

  1. スクラム開発
  2. ドメイン駆動設計←今回のテーマ

スクラムとDDDは通じるところがあるんだなとホッとしました。
開発プロセスと親和性が高くないと進められないですもんね。

DDDに詳しい人がいなかったので、増田 亨さんを招いて学習したとのこと。
増田さんの著書はこちら

今読んでいる途中ですが、全然難しい書きっぷりではないので読みやすいです。

DDDを社内に、他チームに広めなければならない。
そうなったとき、まず社内には変更容易性と属人性の低下というメリットを掲げ、
サービスのトータルコストを削減できることを訴えたそうです。
たしかに、10年20年も続くシステムだという認識が社内に浸透しているなら理解してもらえそう。
そもそもがらっと作り変える可能性のあるシステムであれば、
また別のアプローチを考えないといけないかも。

そしてチームにDDDを広めるためには、
「のれん分け方式」（学んだチームメンバーを分けて別のチームに伝播させる）を行ったそうです。
「DDDをやることは目標ではない」という発言が、
スクラムをやっている私にもハッとさせられました笑

現状はいま半分、50％くらい進んでいるそう。
これから最も腐敗していて最も規模の大きい箇所に進んでいくそうなので、
そこが終わったらまたこういった話を聞きたいなあと思いました。



失敗したことと成功したこと

登壇者：小林映理奈さん
資料：ドメイン駆動設計 失敗したことと成功したこと

こちらでは、具体的なコードとともにドメイン設計のやり方について説明してくださいました。

何かの処理を行う前の前提条件のチェックは、ついアプリケーション層に書いてしまいがちですが
これも業務ロジックなのでドメイン層に当たります。
結果的に、BIGLOBEでは「ドメインサービス」（ドメイン層）を作り、
前提条件のチェックはドメインサービスで行うことにしたそう。

この辺、私はまだDDDについてしっかり勉強しているわけではないので実感が湧いたわけではありませんが、
「ドメインに業務ロジックをすべて集める」だとある程度不都合もあるのかもと理解しました。

その他、具体的なコードは資料を見ていただいたほうが良いので割愛します。

DDDを実践できるエンジニアを育成するための取り組みについて

登壇者：奥野さん
資料：DDDを実践できるエンジニアを育成するための取り組みについて

最後は、BIGLOBEでどうやってDDDを実践できるエンジニアを育てたのか？というセクションでした。
「サービス開発のコストが指数関数的に増加していく現実」があり、
顧客への良いサービス提供のためにDDD導入に至ったという言葉がドキッとしました。
この指数関数的にというのがまさに今私が直面している問題…。
もちろんサービスのバックグラウンドはBIGLOBEと全然異なるのですが、
期間限定のサービスでない限りは基本的に向き合わないと行けない問題なのではと思います。

広めていくための仕組みは、「ルールを作り、チーム全体で共通理解できるようにする」こと。
その方法が「のれん分け方式」で、
練習問題を解く→全員でレビューするという形にし、
わからない点を明確にして知識差を減らす取り組みをしているそう。

推奨した本は2冊。
といってもDomain Driven Design QuicklyはPDF版がダウンロードできるので、
導入コストも低いです。

※その後エヴァンス本も読書会をしたそう。

もちろん育成にはコストがかかります。
そこでコスト、期限、ゴールを決めておくことで、
無限大にコストがかかることを防ぎ、実業務とのバランスをとっていったそうです。

また、設計について思考停止せず考えられるようになったそうで、
結果的にどんどん進化した設計ができるようになってきたとか。



本音トーク

最後に、登壇者＋増田さんでトークの時間。
気になったところだけメモ。

  • ユビキタス言語（共通の業務用語）はコード管理している、非エンジニアにはどう浸透させるかは課題。
  • ちっちゃいクラスがたくさんあるのは気持ち悪いと思ったが、
    やってみたらロジック置くときに便利で意外と使いやすかった
    やらずに判断するのと、やってみるのとはぜんぜん違う by増田さん
  • BPさんはいるが、同じ場所で働いている（スクラムだからかな）
  • のれん分けの期間は最初は半年〜1年、いまは3ヶ月くらい
    いまはちょっと短すぎるくらいかも
  • レガシーなコードは引き続き外注している、外注の人に神がいてすごく早くできる
  • 意思決定はみんなでやる
  • 最初は「俺がルールブック」だったが、今はチームが自走している by増田さん（スクラムとしても羨ましい…）

おわりに

DDDをほとんど理解せず臨んだのですが、
終えた頃にはDDDを学ばなければという使命感に燃えるような満足感のある勉強会でした。
「業務を良くするためにシステムを作っているはずなのに業務がわからない」なんて状態、
エンジニア的にはあるあるだと思います。
（わからないは言いすぎだとしても、詳しくない、よくわからないは同意してもらえるかなと）
業務をそのままシステムに落とすというDDDによって、
それを本来のあるべき流れに変えられるのではないかと感じました。
そしてそれは、
「ちょっと業務が変わったからって改変入ったけど、中身はそんな簡単じゃないんだよ！」という
エンジニアあるあるの怒りも、少しは解消できるのではと思いました。

取り急ぎ、DDDとオブジェクト指向を学んでいます。
実務にもなるべく早く生かしていきたいなと思います。

スポンサーリンク