「ドメイン駆動設計を導入するためにやったこと」(勉強会)に参加してみた感想

はじめに

僕はドメイン駆動設計について、今まで色々本は読んできて、知識としてはある程度ですが、

実際に新規開発する際とか既存システムのリプレイスで導入した経験はない状態です。

そんな中、実際に導入した事例についてお話し頂けるということで、

「ドメイン駆動設計を導入するためにやったこと」という勉強会に参加してきました。

勉強会での内容を気になったポイントに絞ってまとめ、僕の解釈や感想も書いてみました。

2022/3/22追記

今まで僕が参加した回の

現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについて

まとめ記事を作ってみました。

現場から学ぶモデル駆動設計勉強会のまとめ記事

内容

当日の発表資料は＞＞こちら

ドメイン駆動設計のプラクティスでカバーできること、できないこと(松岡 幸一郎さん)

ドメイン駆動設計の目的は、

「ソフトウェアの機能性を高める」ことと「ソフトウェアの保守性を高める」ことである。

何かしらの課題を解決するためにソフトウェアを作るのに、

エンジニアだけで妄想しても本当に役に立つものはできない。

課題に詳しい人たちと一緒になって課題領域のモデリングを行うことで

機能性を高めることにつながり、

そのモデリング結果をソースコードにマッピングしながら落とし込む

＋ドメイン駆動設計のプラクティス(値オブジェクトなど)を使う

ことでさらにソフトウェアの保守性を高めることにもつながるんだ。

というのが僕の解釈です。

ユーザ業務を徹底的に理解する姿勢、

テストコードを書かないと気持ち悪い・モデリングがタスクの最初に入るという文化になった。

この開発チームの文化を変えるというところに関しては、

なぜ、このように設計を変更しなければならないのか？？

ということを開発メンバーに説明して、

具体的な例を上げながら腑に落ちるところまでインプットされたり、

実際にペアプログラミングだったりモデリングを一緒にやったりすることで

文化が変わっていったそうです。

新機能リリースの際はEA(一部ユーザに先行して機能開放)と

GA(全ユーザに機能開放)を行いフィードバックをもらいながら機能追加開発を進める。

ここの話はドメイン駆動開発とは少しそれますが、

僕が今後担当する自社プロダクトにおいてもこの考え方は応用してみたいと思いました。。。

僕の話になりますが、

今担当している自社プロダクトにおいて、

お客さんがいない状態でコンサルメンバーと開発メンバーが一緒になって

こういう機能があれば売れるという妄想をしつつシステム開発を進めたのですが、

結局１社目導入の際、そこまでお客さんが求めておらず、

かなりコストかけて作ったものの、機能を落としたものがいくつもありました。

かなりもったいないな。。。と思っていたのですが、

まずは最低限の機能でリリースしたり、早い段階で実際に先に触ってもらって、

フィードバックをもらいながらシステム開発を進められる仕組みを作れれば

このような事態にはならなかっただろうなと。。。

巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例(ミノ駆動さん)

問題領域と課題領域を整理してコアドメインを見つける。

ドメインエキスパートをフルリモートので探すのにチャット上でずっと絶叫(笑)

既存の巨大レガシーシステムにおいて、

複数問題領域にまたがる課題領域(実態が手作業のものもあった)をまず整理していき、

コアドメイン(コストをかける価値のある一番重要な問題領域)を整理して、

そこに重点的にリソースをかけてコスパよくリファクタリング、

機能追加等していく方針にしているそうです。

巨大レガシーシステムに無限にコストをかけるわけにはいかないため、

コアドメインになる部分のみ既存アーキテクチャを変更してDDDを導入し、

そのほかについてはリソースを割かないようにしている。

巨大レガシーシステムのコアドメインを整理するまでの有識者探しが、

ミノ駆動さんが転職したばかりかつコロナの影響でリモートワークのため大変だったそうです。

もちろん、何年もかけてごちゃごちゃになった

巨大レガシーシステムのコアドメインを整理するのもめちゃくちゃ大変なのでしょうが、、、

プロダクションコードを用いたデザインパターン適用を通じて

開発メンバーへ設計の重要性を浸透させていく。

開発メンバーへドメイン駆動設計を浸透させるため、

実際にグループに分かれてプロダクションコードを題材に、

既存のコードは捨てれる場合一からどう設計しますか？？

というお題で開発を進めることによって、

設計の重要性をチームに浸透させていったそうです。

グループ間でも別々のアプローチで設計していったり、

設計の議論が活発になっていっているそうです。

(この活動は、是非参考にさせて頂こうと思いました。。。

まずは自分が実際にやってみるところからかな、、、)

変更を楽で安全にする良い設計を目指して(増田 亨さん)

増田さんが発表に使われたこちらの資料を参考にするのが早いです・・・

＞＞基幹システムを楽で安全にする

資料にあるように、

数千億円かけて作った大規模システムをドメイン駆動開発でリプレイスすると

開発規模が183千行→97千行

設計書ボリュームが153本(Excelのbook単位らしい)→1本

というように、

同じようなロジックが至るところで書かれていたものがキュッとなったそうです。

さらに仕様変更の際の

変更影響箇所が5千行→9百行

になったりと素晴らしい結果が出てます、、、(めちゃくちゃ大変だけど気持ちいだろうな)

資料にある通りですが、

という考え方の切り替えを行い、開発を進められたそうです。

まとめ

細かいプラクティスに従うことだけにこだわるのではなく、

ドメイン駆動設計の目的を正しく理解し、

機能性を向上させるために、どんな人をどう巻き込んでどう整理するのが効率いいのか？？

整理したものをどう開発につなげる(マッピング)、

どんなテストを書くのが保守性を高めたり品質向上につながるのか？？

を意識して開発を進めることが大事なのだと改めて思いました。

次回、担当するプロダクトにおいては、

ドメインモデリングとまでは行かないにしても、

問題を抱えている人たちを巻き込んで、

同じ目線で議論できる何かしらの資料(できれば開発まで落とし込めるやつ)

を用意して、定期的に議論できる場をセットする。

そんなところから実践できたらなぁと思います。