こんにちは、エンジニアのたべたつ(@ttabtt3)です。この記事はイノベーター・ジャパン Advent Calendar2020 6日目の記事です
弊社で扱っているシステムの一部は創業当初から深くお付き合いがあり、長期間運用され続けているもの(いわゆるレガシーなアプリケーション)があります。
DDDのエッセンスを用いてレガシーなアプリケーションの改善に挑戦したことを2020年の記録として記しておきます。ソースコードなどの細かい話は長くなってしまうので割愛します。
整理整頓
人によって「レガシーシステム」の定義は異なってくると思いますが、今回のレガシーはこちらです。
- テストコードが書かれてない。書けるような設計、実装になっていない
- 手続きが羅列されている状態
- ソースコードを深くまで読み込まないと仕様を理解できない
扱っているシステムは仕様がソースコードのありとあらゆる場所(データベース、ビュー、設定など)に広がっていたので、チームで話し合った結果、本格的なリファクタリングを始める前にプログラムの整理整頓が必要ということで、戦術的DDDという形をとりました。
戦術的DDD(軽量DDD)とは、DDDの本質的な部分である「ユビキタス言語を使ってドメインエキスパートと会話をして、ドメイン知識をソフトウェアにする」といった思想を抜きにして、技術的な部分(Entity、ValueObject、Repositoryなど)のみを取り入れる、というもので、実践ドメイン駆動設計ではアンチパターンとして紹介されています。
アンチパターンと言われていますが、決してメリットがない訳ではなく有識者の中でも肯定的な意見が出ているのを聞きます。
個人としては、本プロジェクトのようにドメインエキスパート(ソフトウェアについて特に詳しい人)が不在だったり、すでに仕様不明でただ動いているプログラムがあるだけ、のような状態の時には情報を整理整頓しつつ進められる有効な手段だと思いました(本格的なDDDを始める前段階として、ですが)
導入にあたって
プロジェクトにこのような概念を導入するにあたって、特に気をつけたことが2つあります。
1つは部分的に、小さく始めることです。
私たちにとっては当たり前のことですが、既存のシステムの改善だからといって動いているものをいきなりリファクタリングせずに、まずは新規で開発する機能のみを対象として、徐々にシステムの闇を明らかにしていく方針をチームで決めて進めました。
コロナウィルス感染症対策のため、リモートでの業務が増え始めたため、距離、時間を意識せずに非同期的なコミュニケーションが取れるようにgithubのissueで意見やサンプルコードを出し合いながら進めました。
2つ目も至極当然のことですが、ドキュメントの整備やサンプルとなるソースコードを継続的にメンテし続けることです。メンバーが入れ替わってもプロジェクトの開発に支障が出ないようにディレクトリの意味だったりモデリングの方法、サンプルとなるソースコードや参考となる文献をgithubのREADMEやesaに記載しておきました。
導入してみた成果
軽量DDDを導入してみた成果としては、今までのソースコードとは別の雰囲気になり、テスト駆動開発ができるようになったりIDEの補完が効くようになったり、値と振る舞いが1つのクラスに閉じていることで、開発速度が向上したり、不具合発生時にどこのソースコードを見たらいいのかが明確なため今までよりも仕様の把握がしやすくなったのではないか、と感じています。
まだ不完全な状態ではありますが探り探り進めていこうと思います。
