DDDを体験できるワークショップイベント「レガシーをぶっつぶせ。現場でDDD！2nd」に参加してきたので振り返り含めたレポートを書いて見ます。
経緯
今勤めている会社のシステムが、一つのモノリスなシステムの上に複数の事業が乗っかっている状態になっています。
この状態ですと、各事業部の機能追加、改修する際にも他の事業への影響を考慮しなくてはならず、そのあたりの調整や影響調査など本来やりたいことと外れたところに労力が必要となります。
このあたりを解消するために、モノリスなシステムを分解して事業にあった適切な単位に分けようと全社的に動いています。
ついては、「事業にあった適切な単位」を見つけるためにDDDの戦略的なパターンが使えないかと思い、今回のイベントに参加しました。
イベント背景
何故このようなイベントが開催されたかについて。connpassに書いてある内容を引用します。
2018年に、経済産業省からこのようなレポートが出ました。レガシーシステムが存在するリスクが書かれており、悲観的な試算だと、2025年以降年間12兆円の損失（東京オリンピックが3兆円）が生まれるとされています。 開発の現場でも、サービス開始から年月が経過することにより、巨大化、複雑化、開発者の増加などをトリガーに、技術的負債に悩まされている現場は多いと思います。
技術的負債に対峙するためには、しっかり設計する以外に方法はありません。そういう意味で、ドメイン駆動設計は方法論のひとつになるのではないでしょうか。
13:30-15:30 D:システム設計の中でのドメインモデルの役割を体感する(萩原)
今回のイベントは2部制となっており、第一部の方ではモデリングのワークショップの方に参加してました。
こちらのワークショップでは、架空の要望管理システムを題材に概念モデリングする、といった内容になってました。
概念モデリングに当たり、最初に時系列の業務フローをまとめ、それをもとに概念モデルに落とすこむ、といった流れでワークしました。
時系列の業務フローをまとめる
アクションを時系列でまとめる際には、以下のような手順でワークしました。
- 関連するステークホルダーを洗い出す（黄色付箋）
- 各ステークホルダー間の関連を簡単に記載する（矢印）
- 時系列に各ステークホルダーが実行するアクションを記載する（ピンク付箋）
- アクションにおいて必要な判断材料などを記載する（オレンジ付箋）。こちらは3と並行して進める
ちなみに、これらの作業は開発チームだけで決めるのではなくドメインエキスパートとのヒアリングを通して進めています。
ワークショップでは意外とすんなりまとめられましたが、このあたりはファシリテーターとドメインエキスパートの能力や相性などに左右されるところなので、実際にやる際には苦労しそうな気がします。
補足
共通処理の扱い
今回の題材の要望管理システムではあらゆるタイミングで利用できるコメント機能というのが存在してました。
これはどのタイミングでも発生し得るため、業務フローとは別に管理したほうが良いかと思いましたが、下手に分けてしまうと概念モデルから抜けてしまう可能性があるため、業務フローには組み込んだほうが良い、という助言をいただきました。
分岐の扱い
今回の業務フローの場合は一本道なので分岐の考慮が不要でしたが、本来の業務フローを分析する際にはいろいろな分岐が想定されます。
書き方は色々あると思いましたが、別の業務フローとしてまとめるやり方が聞いた中だとしっくり来たので、実際に業務フローを整理する際には複数の業務フローをまとめていく感じで進めようと思いました。
ただ、そうなるとワークスペースの確保が大変になりそう。。。
概念モデルを作成する
先に作った業務フローをもとに概念モデル（画像の下の方）を作成しました。
主な流れは、業務フローに登場した概念（青色付箋）とその属性（緑色付箋）を洗い出し、概念間の多重度（青線）とアクティビティ（赤線）をまとめる、といった流れでワークしました。アクティビティではCRUD程度の粒度で今回は記載しています。
概念モデルを作成したあと、業務フローを実現できるかを確認することで、概念モデルの不足部分を確認できました。
補足
詳細の記載
今回の図だと大まかな関係は網羅できてそうなのですが、細かい挙動などの詳細については記載がない状態になってます。
このあたりどうしたらいいんですかねーと、イベントスタッフの方に聞いた覚えはあるのですが、忘れてしまいました（すまぬ）。
個人的な考えでは別色の付箋用意して、そちらで補足するのが良いのではないかと思ってます。
モデルのメンテナンスのタイミング
モデルは機能追加や修正に応じて形を変えていきます。
今回のワークショップでは単純なシステムを例にモデリングしましたが、それでも2時間では足りないくらいでした。
これを細かい機能追加、修正のたびにやるのは結構辛いなーと正直思います。
となると、どのタイミングでモデルをメンテンスするのがいいかと聞いてみましたが、結局時と場合によるので一概に言えない、といった感じでした。
個人的にしっくり来たのが、クロージングワークショップでBIGLOBEの方が言っていた、朝回とかでモデルと実態が合わなくなったタイミングとかでモデル修正する、ってのが気軽でタイミングとしてもよいのではないかなーと思いました。
感想
以前から概念モデル作る際のやり方ってどうするのがいいのかと悩んで、時系列に処理まとめてからそれに当てはまる形で作っていくほうがいいかもなーと考えてました。
今回のワークショップでは実際に考えてたのと近い内容でのモデリングの体験ができて、考えてたやり方が間違いではないことの確認と、具体的な進め方の体験ができて非常に助かる内容でした。
15:45-17:45 C:モデリングワークショップ 〜割り勘ドメイン編〜(かとじゅん)
第二部の方では、ユースケースをもとにモデルを作り、されにモデルをもとにコードに落とし込むまでをやりました。
（自チームの写真撮り忘れた。。。）
流れとしては、すでにユースケースがまとめられている状態で開始し、はじめにモデリングを行い、その後それに合わせてコード（といっても中身のないクラスとメソッド各程度）を書く、といった流れで作業しました。
感想
もともと現職でDDD進める際には概念モデルは作成するが、実コードの方をそちらに合わせるのは余力が出てからと考えていました（エンジニアリソースが足りない、基本Rails使う社内方針でRailsでDDDつらたん）。
ただ、今回実際にコードに落とし込む段階でモデルで抜けている箇所が多く見つかり、コードを書くこともモデリングの手段必要なのではないか、という考えを持つようになりました。
すべての戦術パターンを取り入れるのは厳しいですが、はじめから取り入れやすいものがないか今一度考えてみようかと思います。
クロージングワークショップ
クロージングワークショップでは事前に募集していたDDDに関する質問とその質問に興味持った人数をもとに6つほど質問をピックアップし、それについて話し合う感じで進みました。
自分が参加したのは「DDDを実践するにあたっての見積もりの仕方」についてでした。
ファシリテータやらせてもらいつつ話ししたのですが、自分の誘導の仕方が宜しくなく、「見積もりの仕方」ではなく「社内の説得の仕方」みたいなところに話がぶれたりしましたが、いくつかの学びは得られたかと思ってます。
まず１つとしては、DDDだからといって今までの開発でやってたことが大きく変わるというわけではない、ということです。
基本的な要求分析、要件定義、設計などについてはDDDするにしても必要で、これらの作業がモデリングとして継続的に行われるようになる点が今までと違うところだと考えています。
もう一つは、モデリングの工数は一概に測れない、とういうことです。
初期のスプリントでは業務の分析が不完全でスプリング内でのモデリングの占める割合が大きくなります。（3スプリントくらい？）
一方で業務の分析が進み、開発チームの理解も進んだ段階ではモデリングの占める割合が少なくなり、朝会などでモデルのズレに気づいたら治す程度にまでなる（はず）。
ということで、見積もりとしては初期はモデリングにかかりきりになる分、作業量は増えそうだが事業の分析が進めばモデリングにかかる作業量はそこまで意識せずに住むレベルになる、といったのが自分の中での結論になります。