2018/9/26(水)、「レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡」というイベントに参加しました。
BIGLOBE
様の販売システムに対して、ドメイン駆動設計を適用していった実際のお話が聞けるイベントでした。
「ブログ書きます」枠で参加させていただきましたので、イベント内容等について書きます。
ドメイン駆動設計(DDD)とは
私なりの説明ですが。
説明するのは難しいのですが、システムが対象とするドメインに集中するための一連の技法、といえます。
ドメインを正確に表現するために、
等の手段が取られます。
上の説明が正しいかどうかわかりませんが、実際は非常に難しいです。
いわゆる「エヴァンズ本」といわれる以下の書籍がありますが、一回で理解できるものではありません。
当ブログの以下の記事でDDD
の話も書いてあり、おすすめ本も書いていますので、そちらも参照ください。
BIGLOBEにおける、5年間のDDDへの取り組みと今後について
スライドは以下の通りです。
www.slideshare.net
導入前
ドメイン駆動設計導入前の状態で
- 外注依存
- 開発言語が独自言語
- テストがすべて手動
となっており、その打破のためにアジャイル導入、その後開発言語ドメイン駆動設計導入へ舵を切ったとのことでした。
ただし、オブジェクト指向すらわからない、という状況から始めたそうです。
ドメイン駆動設計を導入するにも、例えば「電話番号」という項目があらゆるところにあり、それがお客様との連絡に使うものか、昼間用の電話番号なのか、意味が推察できないという状況があったそうです。
その意味付けを、ユビキタス言語とドメイン駆動で行うことで、問題解決を図ろうとしたのが始まりのようです。
導入後
導入直後のプロジェクトは、リリースに至らず失敗した、とのことでした。
それでも次のプロジェクトに挑戦し、そちらで成功し、現在の普及に至っているそうです。
当初は5名のチームですが、いまは組織全体で50名がDDD
を実践。
上のスライドの通り、良い効果が出ているそうです。
組織への展開
DDD
のハードルの高さは、最初に述べたとおりです。
独学で学習するのと違って、組織展開となると、学習意欲が低い人に対しても学んでもらう必要が出ます。
そこで取った方法が大変参考になります。
詳細はスライドを読んでいただきたいですが、DDD
をやるメリットがある!と納得してもらうというのは大事なのだと思いました。
失敗した事と成功した事
スライドはこちらです。*1
www.slideshare.net
ドメイン駆動設計では、どこに何を書くかという部分が、重視されます。
レイヤー化、コンテキスト境界外との接続、ドメインの関心事以外の事項等々…
この発表は、実際にどのようなソースになっているか、背景等とともに説明いただきました。
ドメイン欠乏症対策
ドメインの範囲をどうするか、という話です。
この時点でもう、試行錯誤の跡が垣間見えるというか…
つらい現実からドメインを守る3つの盾
こちらも、ドメインの範囲と関わる話です。
現実がどれほど複雑でも、ドメインにその複雑さを持ち込むと、あっという間に汚れてメンテできなくなります。
それをいかに避けるか、これも試行錯誤を感じました。
詳細を書いてもスライドを写すだけになるので、詳細は省きます。
スライドにもありますが、あくまで途中経過で、いまのところ良い感じの方法とのことです。
聞いていて思ったことは、イベント中につぶやいています。
5年でどれだけ試行錯誤したんだろう…結果だけ見たら簡単だけど、苦労ははかり知れない。 #dddalliance
— ひろ (@E2piro) September 26, 2018
スライド中のソースはわかりやすく、説明もできる形になっていますが、ここに至るまでの試行錯誤はどれだけあったのだろう…と思いました。
一度作ったソースを壊して再作成なんて、何度もあっただろうと想像しています。
まあ、より良い設計になるなら修正がなんだ、と個人的には思います。
そのための自動テストでもあります*2。
DDDを実践できるエンジニアを育成するための取り組みについて
スライドはこちらです。
www.slideshare.net
DDD
は実践するのも理解するのも難しい、というのは再三述べている通りです。
やはり、組織で使おうとすると、そこが壁になりますし、そもそも他人にドメイン駆動設計を勧める際にも、とっかかりの難しさは課題になります。
何人かだけ学ぶと、その人に業務が集中して、全体のレベルアップにもならない。そういう課題から。
全員が学ぶべきである、という結論に達したとのことです。
育成方法
講義形式ではなく、練習問題を解く形式にしているそうです。
練習問題二つですが、実践的と感じました。ちょっと改変して取り入れたいぐらいです。
育成そのものはすごくうまくいっているように感じました。
常に問題をブラッシュアップする努力や、レビューアーにとってもメリットのある形式になっていて、運用のことも考えられている仕組みだと思えました。
それだけドメイン駆動設計を中核に据えているとも言えます。
感想
全員でドメイン駆動設計を推進しよう、という体制はどの発表でも感じました。
そして、そのおかげで全員が設計を良くしようというマインドを醸成し、結果的にどんどんシステムが良くなっているのでは、と思います。
新しい設計をだれかが試してくれて、良いものはどんどん取り入れていく
というお話もありました。
全員がシステム作りに参加しているという感覚を味わえるようにも思います。
全体の20%をドメイン駆動設計で書き換えたというお話で、まだまだ先は長いのでしょうが、モデルケースにできるような気がしています。
必要なのは
- チーム全体がドメイン駆動設計を理解する
という点で、それが軌道に乗ることで
- 常に改善する
- コードに語らせる
- 全員が参画意識を持つ
というような状況になっているのでは、と感じました。
ドメインを抽出する話にしても、おそらく誰かが一人で考えても行き詰まっていて、全員で立ち向かって全員が良いと判断できたから、今の形で問題はない、と判断できていると思います。
質疑応答の中で、
みんなで話し合って決めていくのが楽しい
というお話もありました。すごくいいチーム(組織?)だと感じました。
他の場所でもモデルケースとなるような、素晴らしい発表でした。
おわりに
ドメイン駆動設計の話ですが、ValueObject
ってすごく大事だと改めて思いました。
データとロジックを同じ場所に置く
という話もありました。
現在、私はとある分野の管理ソフトみたいなものを作る案件に入っているのですが、現状まだ業務自体がまったく見えてない状態です。
これどこが重要なドメインなんだ、と。
イベント自体はたまたま行けそうだったから、という感じで参加しましたが、これもよいきっかけと思い、改めて勉強しなおそうと思いました。