こんにちは。株式会社estieでソフトウェア・エンジニアをやっています、t-poyoです。
estieでは先日、外部講師として松岡さん（little_hand_s）をお招きしDDD勉強会を2日間にわたり開催しました。
社員エンジニアほぼ全員に加え、業務委託メンバーや入社予定メンバーにも参加いただき、大いに盛り上がりました！
本記事では当日の様子や、得られた知見の一部をお伝えしたいと思います。
なぜいまestieでDDDを学ぶのか？
estieでは現在、不動産データを軸に多数の事業を展開しており、事業それぞれでデータモデリングを行っています。
そのデータモデルをもとに、様々なユースケースに対応できる機能開発を行う必要がある状態です。
従って、不動産データのモデリングは私たちの日常に横たわる最も大きな課題の1つとなっています。「8つの技術的イシュー」と題した弊社の採用資料のセクションでも触れています。
エンジニア採用資料｜株式会社estie / engineer-recruitment - Speaker Deck
このような課題解決にあたり、「方法論の下地としてDDDを学び日々の開発に生かしたい！」との声が社内で以前から多くあり、今回、松岡さんをお招きしての勉強会開催に至りました。
私個人としても松岡さんをTwitterで存じ上げていたので、ご本人とおしゃべりできるのが非常に楽しみでした！
アジェンダ
1日目
- DDDの基本的概念について触れながら、estie社内のプロダクトを例にとり、
システム関連図・ユースケース図・ドメインモデル図を作成
2日目
- サンプルのドメインモデル図をもとにKotlinでサンプルコードを実装
- 2日間を振り返って質疑応答
概念や前提知識については松岡さんの著書「ドメイン駆動設計 サンプルコード&FAQ」を引用しつつ、松岡さんがファシリテーターとなりestieのプロダクトを例にとってDDDの流れをハンズオンしていただきました。
特に1日目は、松岡さんが背景事情・ドメイン知識・ユースケース等をヒアリングしながら進める形式だった為、各図表(システム関連図、ユースケース図…)を書いていく際のポイントや上手な進め方を体験でき、かつDDDの様々なメリットを体感しながら学ぶことができました。
これらの考え方は既に社内で活用されており、ユースケース図・ドメインモデル図を作成し運用しているチームが存在します。
興味深かったポイント
DDDは継続しておこなっていくもので、「作ったら終わり」ではない
そもそもDDDは以下の2つを実現するためにおこなうもの、という前提があります。
機能性(ドメインの問題を解決できる)
保守性(長期的に問題を解決し続けられる)
私のようなDDD未経験者目線だと、2つめの保守性という観点をDDDから汲み取れていませんでした。また「継続しておこなうもの」とも理解しておりませんでした。
しかし実際には、新規機能開発をおこなう時などにモデルを見直し資料をメンテナンスすることで、「何のためにあるのか」「どう使われることを想定しているのか」などについてドメインエキスパートを含む関係者間で認識を合わせ続けることができることを体感できました。
また、そのメンテナンスはユースケース図以外のシステム関連図、ドメインモデル図を対象とするといいという実践的なアドバイスもいただきました。
ドメインモデル整理の後の実装設計については都度考える必要があり、DDDのプラクティスが銀の弾丸となるわけではない
2日目にはモブプロのような形で実際にサンプルコードを実装していただきましたが、松岡さんは「集約」や「コンテクスト境界」といったDDD用語をあまり使わず、あくまで発生した問題に対してDDDのよくあるパターンを適用していくというスタイルで進められていたのが印象的でした。
DDDの考え方や実装パターンは、問題解決のために用いる道具であり、DDDをやるからといって「DDDっぽい実装」を最初からやりすぎる必要はないんだなと感じました。
質疑応答を一部紹介
2日間の勉強会を通して、参加者から多数の(20個くらいありました)質問が出ましたが、その全てに丁寧に答えてくださいました。また、よくある質問については松岡さんのブログで既に情報が整理されおり、プロフェッショナルを感じました。リンクとともに、質疑応答の一部を紹介します。
Q. DDDの失敗例はありますか？
A.モデリングの失敗ではそんなにないかもしれません。失敗したり違うなと思ったら直していくので、ずれていたら直していきます。モデル図をテキストでメンテしようとしたこともありましたが、具体例の大事さを感じてから無理だなと感じてやめたことはあります。コードでいうとDDD っぽいコードを推進していくことは工夫とか時間が必要です。誰かしらが吸収しながらお手本を作る形がよいと思います。
Q. 隣接ドメインで複数サービスを立ち上げている為、コンテクストを跨いで共通の名称を持ったモデルが多数生まれてきています(ex. estieのどのサービスにも物件”building”は出てくる、等)。チームを跨いだメンバーとの会話で認識の齟齬を生まないためにはどうすればよいでしょうか？
A.色んなコンテクストを盛り込みすぎると非常にファットなモデルになってしまいます。そこを境界づけられたコンテキストにすることによって（明確に境界を定めることによって）分けていくのが良いでしょう。コンテクストをまたいだということであれば別のものと考えてあげたほうがいいと思います。
Q. Domain, Application レイヤーと Interface Adapter レイヤー間のDTOを書くのが面倒くさいと言われることが多いです。実際各行数は増えるので、開発コストに対してメリットのトレードオフとDTOを省略できる場合などあれば伺いたいです。
A.application層の戻り値を、presentationの戻り値でも使用しちゃうことはあります。その2つが別の型や挙動を持ちたくなったらタイミングで分けるとかはありですね。ただ、同じ名前の属性のみ＆マルチカーソル使えばそんなにめんどくさがらずに行けたりします。
Q. 実際のところ、どのようにDDDを続けていけば良いか迷いそうです。いつどのようにメンテナンスするのが良いのでしょう？
A.新規機能などを作るタイミングで、既存のモデルを整理するとよいです。それらをどう拡張するのか、という話をビジネスに詳しいドメインエキスパートを巻き込んで議論していくのがおすすめです。 とはいえ、それなりに工数がかかるので、過去に作ってある部分で直近触らないものなどは後回しにしてスコープから外すのもありですね。
DDD関連のドキュメントは、作って捨てるその回限りのものとメンテしていくものを明確にしていくとよいです。ユースケース図は捨ててもいいが、ドメインモデル図はメンテする…など。ユビキタス言語はドメインモデル図をマスターにして一緒に管理するのが、情報が散らばらないのでおすすめです。
最後に
DDD勉強会で得た内容をもとに、既に複数のチームでドメインモデリングを実践し、良い影響が出始めています。こちらは実践編として、別の記事でご紹介する予定です。松岡さん、有意義な時間を本当にありがとうございました！
ドメインエキスパートを巻き込んだデータモデリングに興味のある方は、カジュアル面談でお話ししましょう！
