【参加レポート】レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡

2018/09/26にBIGLOBEさんで開催された「レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡」にブログ枠で参加した。私はDDDを実践したことはなく、知識もほとんどなかったため、『わかる!ドメイン駆動設計 ~もちこちゃんの大冒険~』を読んで入門的な知識を付けてからイベントに臨んだ。

以下、イベントの参加レポートである。


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

概要

30年間、事業を支えてきた業務システムをDDDで刷新する。そのためには、組織的、エンジニアのレベルなど多くの問題があります。その壁をどう乗り越えたのか? そして、壁の向こうで得た恩恵とは何なのか?5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。

発表者

西 秀和(にし ひでかず)さん

ビッグローブ株式会社 マイグレーション 開発リーダー

2016年にBIGLOBEに入社。サーバサイドエンジニアで、入社以前から長年、BIGLOBEの光回線事業を担当。入社後は、BIGLOBEのサーバサイドのアーキテクチャ刷新のために、マイグレーションプロジェクトに従事。現在、腐敗層と戦争中。


アジェンダ
  1. DDD導入に至るまで
  2. 導入時の苦労
  3. 導入による効果
  4. 今後の目標
  • API・バッチ本数が6500本、独自言語で作られ外注先の開発者しか仕様が分からないBIGLOBE販売システムに5年かけてDDDを適用した話
    • 詳細についてはスライド参照。

所感

5年という歳月の激闘を約30分の発表に凝縮していただけたことにまず感謝したい。導入前の絶望的な状況や導入後の難航具合を伺う限り、心が何度も折れそうになったであろうことは想像に難くない。しかし、真摯に取り組みを続け、DDD適用範囲を広げることに成功したその継続力こそが、BIGLOBEさんの強さではないだろうか。腐敗層を駆逐した暁には、再び発表を聴いてみたい。


ドメイン駆動設計 失敗したことと成功したこと

概要

その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。5年という歳月はそれを気づかせるには十分な時間で、DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。そのコードは何を失敗していたのか?そして、それは改善するために改善した事とは?BIGLOBEにおける”今”のいいコードの書き方をできる限り具体的な事例を元に紹介します。

発表者

小林 映里奈(こばやし えりな)さん

ビッグローブ株式会社 ビッグローブ光 開発担当

2015年度入社。光回線事業の開発チームに所属。ビッグローブ光の業務システムの設計・開発を担当。


アジェンダ
  1. ドメイン欠乏症との戦い ~実践と結果~
  2. つらい現実からドメインを守る3つの盾
  • ドメインにロジックを書くことを実現するための試行錯誤について、サンプルコードで解説
    • ドメイン欠乏症対策を行って、中身の詰まったドメインをつくる
  • 内部からはドメインを充実させる一方、外部からは現実が攻めてくる
    • 現実からドメインを守るための3つの盾
      • form/request
        • 複雑なバリデーションルールからドメインを守る
      • converter
        • 複雑なIF仕様からドメインを守る
      • adapter
        • 物理データ構造からドメインを守る
  • 詳細はスライド参照

所感

サンプルコードを交えながら、ドメインを守りながら現実と戦う具体的な方法を学ぶことができる、きわめて実践的な発表だった。試行錯誤の過程がまとめられており、DDDの知識が乏しい私でも非常に理解しやすかった。小林さんが入社されたときには既にDDDの取り組みが始まっており、いわばDDDネイティブになるわけだが、(つらみも多いであろうが)そのような環境で仕事ができることについては素直に羨ましいと感じた。


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

概要

スキルも背景も異なるメンバーにDDDを理解し実践してもうため、BIGLOBEの現場で行っている育成事例を紹介したいと思います。DDDを実践するための基礎となるスキル(オブジェクト指向、レイヤー設計)の育成や、ある課題に仕様変更を繰り返すことで変更に強いモデルの考え方を体感して理解してもらうなど、5年間で試行錯誤してきた取り組みについて発表します。

発表者

奥野 雄一(おくの ゆういち)さん

ビッグローブ株式会社 BIGLOBEモバイル 開発リーダー2007年度に入社後、インフラ部門を経て、システム開発を担当。現在はMVNO事業のシステム開発に従事。1年前よりDDD教育に取り組み、新規参画者の理解促進、チーム合流コストの削減に努める。


アジェンダ
  1. 育成に取り組んだ背景
  2. 具体的な取り組み内容
  3. 取り組んでみて見えてきた課題
スライドに登場する参考書籍(導入時の教材)
※DDD Quicklyは無料で見られる

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

  • 詳細はスライド参照

所感

これまでの発表を通じて、DDDは少しでも油断すると手段と目的を取り違える開発手法であるように感じた。育成の際にDDDを目的とさせないようなディレクションに苦心されてきたことが垣間見えた。チームで練習問題に取り組む形式でDDDを学ぶスタイルが非常に参考になった。


BIGLOBEエンジニアの本音トークを聞いてみよう

モデレータ

増田 亨(ますだ とおる)さん

有限会社システム設計 代表

登壇者

  • 西 秀和さん
  • 小林 映里奈さん
  • 奥野 雄一さん
  • ユビキタス言語のチーム内管理はどうやっているのか?
    • Wikiは破たんする
      • 皆管理が嫌い
    • コードに落としてしまう
      • できる限りコード上で日本語を使う(enumとか)
    • 実務担当者が新しい業務用語を生み出しているときは、新たなユビキタス言語を作るとき
      • 開発者がそこに追従する
      • 知らない単語を聴いたときはリファクタが必要なとき
  • converterの仕様すり合わせはどうやっている?
    • 仕様を提示する外部の会社とすり合わせている
      • 課題管理表ベース
        • ライフライクルなどの観点を見ている
    • 社内で置き換えると何になるか考える
      • データの意味づけを明確にし、とりあえず置き換えてみる
        • 間違っていたらリファクタ(期間が経って分かることもある)
        • それを見越してマッピングしておく
  • DDDを会社として取り組もうという状況ではないとき、どのような取り組みをしてきたか?
    • 必要があればValueObjectを使えばいいと思ったが、ValueObjectを作っていないと、皆は今あるロジックに置き場所を求める
    • データがある場所にロジックを書きましょうというルールを作る
      • ルールを先に作り、後で実感してもらう
        • ValueObjectの小さいクラスがたくさんあるのは反発されなかったか?
          • とりあえずやってみろと言われやってみたら、それほど大変ではなかった
          • 食わず嫌いの壁を越えられるかどうか
            • 一回超えてみればよさがわかる
          • 経験していなくて嫌だと、経験して嫌だ、は全然違う
            • まずは書いたものを見てもらい、コードで話す
              • 最初はelse禁止とか、メソッド引数禁止とか言われたので、ValueObjectくらいは大したことないと感じた
  • 未だに外注を使っているのか?
    • まだ協力会社はいるが、基本的には現場に来てもらっている
  • 外注のエンジニアにもDDD育成をしているのか?
    • いっしょにやっている
  • のれんわけはどれくらいの期間で別れていくのか?
    • 最初は半年~1年くらいはチームを変えなかった
    • ある程度人数が増えたら三か月に一回は変えている
      • 三か月以内だと短すぎるのでチームが立ち上がらないので伸ばそうとしている
  • DDDベースでやっていると技術力のある人が集まってくるのか?
    • まだ集まってきていない
  • converterやadapterのマッパー実装地獄が容易に想像できるが、そこで工夫していることは?
    • 100や200とマッパーの数が増えるとミスも増えてくる
    • 人為的なミスはユニットテストで防ぐ
    • converterもテストしている
    • つらいが導入前よりは絶対によい
      • 極端な例
        • A3用紙2枚分くらいの項目がひとつのIFにあったりする
          • パースしたデータは70テーブルに該当する
  • クラス図は必ずメンテしているのか?
    • 重要なメソッドくらいしかメンテしていない
    • PlantUML使ってテキストベースでメンテ
    • エンティティや依存関係の変更があるときは必ずクラス図に反映させる
    • 少しでもメンテをさぼるとすぐに陳腐化する
    • 実装の設計図レベルのクラス図は書いていない
      • システム的に重要な点を重視して書いている
    • スライド内のシーケンス図は日常的に書いているか?
      • 必要に応じて書いているが、最近はシーケンス図よりクラス図が多くなってきている
        • どれくらい図を残すかはチーム内で共有できている?
          • ばらつきが大きい
  • レガシコードにはどう対応しているのか?
    • レガシーなところは経験のある外注に頼っている
      • 新規プロジェクトには社内でDDDを適応している
  • ユニットテストをどこまで書いているのか?
    • 基本的にはほぼすべて書いている
    • マッパーはドメイン単位で書いている
  • 設計における最終的な意思決定者がいるのか?
    • 基本的にはいない
    • チーム内で議論して解釈の違いをすり合わせていく
  • テストコード書きすぎという議論はでてこないのか?
    • 書かないとコードレビューが通らない
      • それはルールなのか?本当に必要なのか?
        • まだまだテストは足りていないなという感覚
  • クラスが膨大になってくる中でパッケージの分け方は?
    • 基本的にはレイヤーアーキテクチャ
    • ドメインについての特別規約はないので皆で議論して決めていく
      • 外から来るデータを受けるレイヤーはなるべく小さく
      • 20も30もクラスがあるパッケージはない
      • ビジネスの概念でグルーピングを重視している

おわりに

DDDの知識も経験もほとんどないまま乗り込んだイベントだったが、どの発表も引き込まれるものがあり、DDDの学習意欲を刺激された2時間だった。5年間という決して短くない時間の中で、失敗を繰り返しながらも歩みを止めなかったBIGLOBEの皆様が得た知見を惜しみなく提供していただき、学ぶものしかないイベントだった。私自身レガシーコードに立ち向かう機会も多いので、立ち向かうための武器の一つとしてDDDを習得していきたい。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です