途中から始めてるDDD

AdventCalendar2018 ddd lobi

Lobi事業部の長田です。 Tech KAYAC Advevtent Calendar 2018、17日目の記事です。

TL;DR

  • DDDを実践して半年ほど
  • コンテキスト分割して実験できる環境を作るのは良い
  • 自分たちが何を作っているのかを考える必要があるのは良い
  • イニシャルコストと開発工数の増加は避けられない

どこで始めているのか

カヤックにはLobiという2010年から運用を続けているサービスがあります。 https://web.lobi.co

運用期間が長いシステムによくある悩みとして、 経年劣化で様々な箇所で問題が発生しつつあります。

その中でもソースコードの問題として、

  • 締切に追われて書いた！動いた！のはいいものの、その後リファクタリングされなかったコード
  • 提供終了したにもかかわらず、削除されていないコード
  • 肥大化したUserモジュール

などなど、該当箇所を触るたびにつらい思いをすることが増えてきました。 これらを解決する手段として、DDDの実践を半年ほど前から行っています。

今回はDDDの実践によって得られた知見を紹介します。 なお、DDDそのものの解説は割愛します。

やってよかったこと

コンテキスト分割

新機能をひとつのコンテキストとして実装しています。 新機能を対象に選んだのは、DDD未成熟な開発チームが複雑に入り組んだ既存コードを リファクタリングしながら実践するのは非常にコストが高いと判断したためです。 また、比較的小さな単位でコンテキストに分割しています。

こうすることによって、

  • 既存コードとの関わりをACLに閉じ込められる
  • 実験的な設計を影響範囲少なく試用することができる

という恩恵がありました。

「何を作っているのか」をよく考える

これが最も大きな恩恵だと考えています。 DDD実践以前は「どうやって結果を得るか」を中心に考えていましたが、 実践移行は「それは一体何なのか」をよく考えるようになりました。

結果としてより自然な設計を選択できる確率が高くなりましたし、 自分たちがユーザーに提供しているものについて理解を深めることができるようになりました。

デザインパターンの実践

「何を作っているのか」にフォーカスする上でそれ以外の関心事を分離するために、 各種デザインパターンを採用することで実績のある良い設計を選択することができます。 これにより今までは意識せずに使っていたパターンや、使い所がピンときていなかったパターンなどが、 効果的に利用できると感じる場面が増えました。

わかっていたけど大変なこと

新規メンバーのイニシャルコスト増加

DDDに慣れるまでは、とにかく何を言っているのか分からない状態が続きます。 理解が進んでいる人と入門者では正直会話もままなりません。 実際自分も新米エンジニアの気持ちを思い出しました。 そのくらい「何を言っているのか分からない」状態になります。

会話できる状態までDDDの基礎に馴染むためのイニシャルコストがどうしても必要になります。 人にもよりますが、1〜3ヶ月程度は必要だと感じました。

開発工数の増加

「何を作っているのかを深く考え」て、「レイヤー構造をしっかり分け」と、「適切なデザインパターンを選択」し・・・ とやっていると必然的に開発工数は増加します。 長期運用を見据えた上でDDD実践を選択したので、開発工数が増加することは承知の上だったのですが、 特に慣れないうちは見積もりとの乖離が大きくなってしまいがちでした。

これらの開発コスト増を踏まえて、「緊急を要する不具合改修時はDDDのことを考えない」などの 場合に応じた割り切りが必要になります。

改善できること

開発コストと向き合う

開発メンバーがDDDに慣れることによって、開発工数を短縮することができます。 開発チーム内はもちろん、社内にDDDを理解している人が増えれば、 スポット的な開発リソースの貸し借りもやりやすくなります。

動くものが見れるようになるまで時間がかかるというのが問題なのであれば、 仮実装を挟むことによってすばやく動くものを完成させて全体感を掴んでから DDDを使った本実装に移るという手段もあります。

なにより「長期運用を可能にするために必要なコスト」であることを 事業部内の共通認識にすることが大事だと考えています。

プロジェクト内でのDDD定型化

「よかったこと」の中で

  • 実験的な設計を影響範囲少なく実験することができる

と書きましたが、実験しながら求められている機能を実装するのはなかなかにしんどいものです。 半年間の実験である程度の知見を得ることができたので、 それらをまとめて開発チーム内でDDDフォーマットをつくるフェーズに入ってきています。

ユビキタス言語の普及

DDDを実践した結果得られるもので最も大きな恩恵である、 「ユビキタス言語をそのままコードに落とし込む」事がまだできていません。 これはDDDを意識しているのがサーバーサイドの開発メンバーに限られていることに起因します。 クライアントサイドの開発メンバー、及び非エンジニアにも 「ユビキタス言語で話す」「ユビキタス言語について考える」ことを定着させていく必要があります。

おわり

まだまだ改善点の残るDDD実践ですが、 プロジェクトが良くなっていく手応えは感じています。

明日は「kuiperbeltの新機能 gRPC Adapterを使ったSocket.IO対応」だそうです。 おたのしみに。