[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance

PR新メンバーズ

こんにちは。プロダクトグループのshoito(しょいと)です。

9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった 5 年間の軌跡 に参加してきたのでレポートします。

当日のtwitterのハッシュタグ#DDDAllianceで参加者のツイートが見られます。

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

ビッグローブ株式会社 西 秀和さんより

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

アジェンダ

  1. DDD導入に至るまで
  2. 導入時の苦労
  3. 導入による効果
  4. 今後の目標

BIGLOBE販売システムについて、DDDを適用した5年間の話。
本システムは以下のような複雑な背景があり、機能の追加/変更にコストがかかり過ぎて、変更が困難だという課題を抱えていた。

  • API・バッチ本数、合計6,500本
  • 開発は外注していたため、サブシステム毎に開発会社が違う
  • 全体を把握している人がいない
  • 開発言語が独自
  • テストが全て手動
  • ...

改革の流れ

  1. スクラムから取り組んで開発プロセス改革へ
  2. 独自言語からJava/Spring、VimからIDE、Windows -> Macへなど開発環境改革へ
  3. 設計・実装のやり方を変えるためにDDD導入へ

DDD導入については、独学では無理だということで、DDD先駆者の増田さんにメンターを依頼。
はじめての実プロジェクトでは、全く納期に間に合わず失敗。
挫けずに、メンターに励ましてもらいつつ、組織へ展開、エンジニア育成し、継続中。
プロダクトコード、テストコードがそれぞれ100万行あり、現在は全体の20%程度にDDDを適用した。
今後の目標としては、腐敗層の駆逐、RDRAによる要件定義との連携、マイクロサービス化など。

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

ビッグローブ株式会社 小林 映里奈さん

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

アジェンダ

  1. ドメイン欠乏症との戦い〜実践と結果〜
  2. つらい現実からドメインを守る3つの盾

DDDを適用することで設計がどう改善されていくか試行錯誤の仮定を含めてサンプルコードで解説。

ドメインを守るための3つの盾について、コードで紹介

  • form/request: 複雑なバリデーションルールから守る
  • converter: 複雑なインターフェースから守る
  • adapter: 物理データ構造から守る
PR新メンバーズ

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

ビッグローブ株式会社 奥野 雄一さん

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

アジェンダ

  • 育成に取り組んだ背景
  • 取り組み内容
  • 取り組みにより見えてきた課題

DDDが何か理解していない開発メンバーがほとんど。
設計のガイドライン・ルールを決めドキュメント化するのでは上手くいかない。
DDDの基本的な考え方をチーム全体の共通理解にしていく。

組織への展開方法として、のれん分け方式
ノウハウを理解したメンバーを分けて新しいチームを立ち上げ、メンバーを育成していく。

DDDが何かを知るために、まず以下の2つを読む。

練習問題に対して、以下を実施して学習する。

  1. ドメインモデルの作成
  2. チームメンバーでのレビュー
  3. 実装
  4. プルリクエストベースでのレビュー

育成にはコストがかかる。
レビューにはメンバーのコストもかかる。
育成にコストをかけすぎないようにQCDを決めておく。

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

  • モデレータ 増田 亨さん
  • 登壇者の3名
    • 西 秀和さん
    • 小林 映里奈さん
    • 奥野 雄一さん

会場からの質問

Q1.
ユビキタス言語のチーム内での管理はどうしているか？

A.
Confluenceでの管理を考えたがメンテされずに破綻した。
できる限りコードに落としてコードで管理している。
Enumの定義やメソッドに日本語を使って表現している。

Q2.
外部仕様を出す人たちと開発側での用語のすり合わせはどうしているか？

A.
外部の会社と課題管理表ベースでやり取りしながら深掘りしていっている。
変化することを前提にまとめて、変わったらリファクタリングしている。

Q3. DDDの適用への反発に対して、どう取り組んだか？

A. ValueObjectを先に用意しておいて、データのある場所にロジックを書くように促した。
まずは経験してもらうために、最初にコードで現した。
意識的に厳し目の例で体験してもらい理解してもらう。

Q4.
はじめてのプロジェクトの規模は？

A.
開発メンバーは5名。
次のプロジェクトは同じサービス(バージョン2)を対象に7名。
コード行数としては1万行程度。

Q5.
今も外注の形なのか？
外部のエンジニアの育成もしているのか？
のれんが分けにかかる期間は？

A.
まだ協力会社のメンバーと同じチームで開発している。
同じチームであるため、会社をまたいで育成している。
はじめの1, 2年はチームを変えていなかった。
今は3ヶ月に1度程度でチームを変えている。
最近は3ヶ月では短いということで伸ばそうとしている。

Q6.
技術力が上がってきて、レベルの高いエンジニアが集まってきているのか？

A.
まだ効果は現れてないため、絶賛募集中！

Q7.
ConverterやAdapter ドメインを守るために必要だとは思う マッパー地獄になりそう それへの対処はどうしてる？

A.
そもそもつらい。
人為的なミスはユニットテストで防ぐ。

Q8.
外部インターフェース仕様が変わるときに、どれくらいのサイクルで適用されるか？
(70テーブル、300項目あるインターフェース仕様...)

A.
数ヶ月。
やりたくないので担当者はルーレットで決める...。

Q9.
スライドにクラス図が見えたが変更がある度にメンテナンスしているのか？

A.
残しておかなければならない依存関係や重要なEntityやValueObjectしかメンテナンス対象にしていない。
PlantUMLを使ってテキストベースで管理している。
チームによってクラス図、シーケンス図をどれくらい描くのかは違っている。

Q10.
レガシーコードはどうしているか？

A.
経験の豊かな協力パートナーのエンジニアにお願いしている。

Q11.
ユニットテストはどこまで書いているか？
コードの全体的な意思決定者はいるのか？

A.
ユニットテストはほとんど全部書いている。
ロジックのある部分には全て書くようにしている。

全体的な意思決定者はいない。
チーム内で協議して意思決定している。
考え方の違いなどを議論して、設計段階で気付きを得たい。

Q12.
プロダクトコード100万行に対して、テストコード100万行は書きすぎでは？

A.
テストコードがないとレビューが通らないので。

Q13.
ソースコードのディレクトリ構成、パッケージ分割の方法や規約は決めているか？

A.
レイヤーアーキテクチャに則ったやり方でやる。
ドメイン層はチームで決めて納得した形で規約はない。
大きくなってきたら見直す。
1パッケージに20や30クラスが入ったものはなく小さく分けられている。

おわりに

ビッグローブ様でのレガシーコードに対してDDD導入を実践した5年間の知見を惜しみなく公開してくれた勉強会でした。
DDD導入の背景からDDD適用プロジェクトでの失敗、エンジニア育成、現場での設計・実装の具体例など、学ぶものが多かったです。

新たな技術を導入する際には、先駆者のメンター採用が効果的なんだなと、全セッションを通して感じました。

PR満足度98%