Menuゆるtech。「レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡」というイベントに参加してきました。実はDDDの知識はほぼゼロで、ただ「レガシーなコードをイケてるコードに書き換えたメソッドを知りたい」と思い勢いで申し込みました。個人的に響いたところ(だけ!)を記事にしてみます。内容が気になった方はぜひ実際の資料をご覧いただければと思います。大規模でレガシーでメンテナンス性の低いソースコードを、スクラム開発とドメイン駆動設計で刷新している途中とのこと。手動テストLinuxなのにWinというなかなかのおっかなさには会場に笑い(失笑?)が。機能追加、変更の影響調査に時間がかかる詳細設計は末端の開発者しかわからないという2点。状況は全く違いますが、私のところとも通じる問題点だなと思いました。その打開策として行ったのが2点。スクラム開発ドメイン駆動設計←今回のテーマスクラムとDDDは通じるところがあるんだなとホッとしました。開発プロセスと親和性が高くないと進められないですもんね。亨さんを招いて学習したとのこと。増田さんの著書はこちら今読んでいる途中ですが、全然難しい書きっぷりではないので読みやすいです。DDDを社内に、他チームに広めなければならない。なったとき、まず社内には変更容易性と属人性の低下というメリットを掲げ、サービスのトータルコストを削減できることを訴えたそうです。たしかに、10年20年も続くシステムだという認識が社内に浸透しているなら理解してもらえそう。そもそもがらっと作り変える可能性のあるシステムであれば、また別のアプローチを考えないといけないかも。「のれん分け方式」(学んだチームメンバーを分けて別のチームに伝播させる)を行ったそうです。現状はいま半分、50%くらい進んでいるそう。これから最も腐敗していて最も規模の大きい箇所に進んでいくそうなので、そこが終わったらまたこういった話を聞きたいなあと思いました。失敗したことと成功したことこちらでは、具体的なコードとともにドメイン設計のやり方について説明してくださいました。何かの処理を行う前の前提条件のチェックは、ついアプリケーション層に書いてしまいがちですがこれも業務ロジックなのでドメイン層に当たります。前提条件のチェックはドメインサービスで行うことにしたそう。「ドメインに業務ロジックをすべて集める」だとある程度不都合もあるのかもと理解しました。その他、具体的なコードは資料を見ていただいたほうが良いので割愛します。DDDを実践できるエンジニアを育成するための取り組みについて登壇者:奥野さん資料:DDDを実践できるエンジニアを育成するための取り組みについて最後は、BIGLOBEでどうやってDDDを実践できるエンジニアを育てたのか?というセクションでした。顧客への良いサービス提供のためにDDD導入に至ったという言葉がドキッとしました。この指数関数的にというのがまさに今私が直面している問題...。期間限定のサービスでない限りは基本的に向き合わないと行けない問題なのではと思います。広めていくための仕組みは、「ルールを作り、チーム全体で共通理解できるようにする」こと。練習問題を解く→全員でレビューするという形にし、わからない点を明確にして知識差を減らす取り組みをしているそう。導入コストも低いです。※その後エヴァンス本も読書会をしたそう。育成にはコストがかかります。無限大にコストがかかることを防ぎ、実業務とのバランスをとっていったそうです。結果的にどんどん進化した設計ができるようになってきたとか。本音トーク最後に、登壇者+増田さんでトークの時間。気になったところだけメモ。ユビキタス言語(共通の業務用語)はコード管理している、非エンジニアにはどう浸透させるかは課題。終えた頃にはDDDを学ばなければという使命感に燃えるような満足感のある勉強会でした。「業務を良くするためにシステムを作っているはずなのに業務がわからない」なんて状態、エンジニア的にはあるあるだと思います。(わからないは言いすぎだとしても、詳しくない、よくわからないは同意してもらえるかなと)業務をそのままシステムに落とすというDDDによって、それを本来のあるべき流れに変えられるのではないかと感じました。「ちょっと業務が変わったからって改変入ったけど、中身はそんな簡単じゃないんだよ!」というエンジニアあるあるの怒りも、少しは解消できるのではと思いました。取り急ぎ、DDDとオブジェクト指向を学んでいます。実務にもなるべく早く生かしていきたいなと思います。