まえがき

書籍でDDDの学習を進めるうちに、モデリングの理論やメリデメの記載はあったのですが、実際の現場でどうやってモデリングが進めていいのかイメージができないままでした。

そんななか松岡さん(@little_hand_s)のライブモデリングの動画を見つけ、あくまで一例ではありますが、ゼロから試行錯誤しつつモデリングしていく様子が見れてたくさん学びがありました。

松岡さんは「ドメイン駆動設計 モデリング/実装ガイド」や「ドメイン駆動設計 サンプルコード&FAQ」の著者であり、DDD Community JPの主催者です。DDDの質問回答やYoutubeでの発信、イベント主催など積極的に活動されています。

今回は、ライブモデリングを視聴した気づきと、実際に自分もモデリングをしてみた所感をこちらにまとめたいと思います。

前提

DDDを導入するメリット

DDD(ドメイン駆動設計)とはソフトウェア設計手法のひとつです。
ライブモデリングの話の前に、DDDが実現しようとしているものはなにかという説明からさせてください。公式のリファレンスに記載されているDDDの目的は以下の通りです。

ここでいわれている「利益」とは、実際にソフトウェアが現場が抱えている問題を解決することだと松岡さんは動画内で解釈しています。

モデリングとはなにか

DDDは下記のような２種類のフェーズを必要に応じて反復しながら、開発を進めていきます。モデリングはそのなかで「ドメイン」→「ドメインモデル」への抽象化を担当します。

モデリングフェーズ
ドメイン → ドメインモデル

実装フェーズ
ドメインモデル→ソースコード

ここでいうドメインとは「ソフトウェアで問題解決しようとする領域」のことで、たとえばいままで手作業でやっていた予約管理をオートメーションしたい場合、予約管理システムにおけるドメインは「既存の予約管理業務」になります。

ドメインモデルはドメインをソースコードに落とし込めるように抽象化したもので、モデリングのフェーズには開発者だけでなくビジネスサイドの事業者も含めてモデリングを進めることが推奨されます。

ライブモデリングを視聴した気づき

ライブモデリングの概要

ライブモデリングでは「sudoモデリング」という方法を紹介しつつ、エンジニア/ドメインエキスパート(ドメインについて詳しい利害関係者)を一人二役で演じながら採用管理システムのモデリングをデモンストレーションしています。
「sudoモデリング」とは以下の4つの図の頭文字をつなげた造語です。
・システム関連図
・ユースケース図
・ドメインモデル図
・オブジェクト図

名称だけだとイメージが湧きにくいかと思いますので、実際の図を見ながら説明していきます。

システム関連図

システム関連図は「誰がこのシステムを使うのか」と「外部システムとの関連」を整理するための図です。シンプルな図ではありますが、システムの前提やコアな要件を決定するので非常に重要な図です。
例えば今回の場合、応募者がこのシステムを利用するのかどうかによって要件や工数は大きく変わってきます。(応募者が利用する場合、応募者のログイン機能や登録処理などの実装が必要になってきます)

ユースケース図

ユースケース図はユーザーの要求に対しシステムのふるまいを定義するための図です。

ドメインモデル図 / オブジェクト図

ドメインモデル図はドメインを抽象化したクラス図のようなもので、オブジェクト図はドメインモデルの具体例を記した図です。
松岡さんはドメインモデル図に関して何点かルールを設けています。

• ルール/制約(ドメイン知識)を吹き出しに書き出す

• オブジェクト同士の関係性や多重度を定義する

• 日本語や英語の対訳を定義する

などです。ライブモデリングのなかではドメインモデル図(抽象)とオブジェクト図(具体)を往復しながらドメインモデルをブラッシュアップしています。

ライブモデリングから得た気づき

最初から100%のドキュメントを作ろうとしない

• 運用してみないと判断しにくい事項や、「MUST」ではなく「WANT」ぐらいの温度感の機能など、現段階で決めきれないものも積極的に記載する

•  モデリングに現場の関係者全員に参加してもらうことは現実的ではないので、その場にいない関係者に確認すべきことは「宿題」として書いておく

作図中の変更はその場で他の図に反映する

• それぞれの図で変更があった場合は他の図にも変更内容を反映して、図を行ったり来たりしながらブラッシュアップする

• 変更の反映を面倒臭がらず、その場で反映する

• ただ実際は色んな人がドキュメントの同時に修正するシチェーションもあると思うのでルールの策定は必要かも

ドメインモデルがユビキタス言語の原本になる

ユビキタス言語は単語帳っぽいものを想像していたが、図で管理するほうが良さそう。理由は以下の通り

• モデル同士の関係性や集約の範囲を表現しやすいため

• 非エンジニアや現場の人も直感的に理解しやすいため

• メンテナンスがしやすい

ユビキタス言語は「和名/英名」のセットで定義する

• ユビキタス言語は「和名/英名」のセットで定義することで、コーディングする人による変数名・関数名のブレや新規参画者が変数名・関数名で悩むといった問題を解決できる

ライブモデリングをやってみた

「習うより慣れろ」ということで、自分も一人二役で試行錯誤しながらモデリングを実践してみました。今回の題材は「バスツアー予約管理システム」です。

完成したもの

システム関連図

「バスツアー予約管理システムをだれが使うのか」「連携する他システムはなにか」を中心に作図しました。今回は同会社にツアー企画者・ドライバー・バスガイドが社員として所属している前提で考えました。
（もしツアー企画者が所属する会社とドライバー・バスガイドを派遣している会社が別の場合は以下のようにならないと思います)

ユースケース図

参加者側と運営でそれぞれどんなユースケースが必要かを洗い出して作図しました。逆にシステムで対応しないユースケース(出欠管理・ツアー料金の決済)も定義しました。
システムで対応するユースケースのなかでも、優先度によって区分けしたほうが良かったかもしれません。

ドメインモデル図 / オブジェクト図

ライブモデリング同様に、ドメインモデル図とオブジェクト図を往復しながら作図しました。
まだ決めきれていない制約はいくつかありますが、正直実装を進めてみないと分からない部分も多そうなので、コーディングしながらブラッシュアップしようと思います。

所感

• ひとまず暫定で決めておいて、それぞれの図を行ったり来たりしながらドメインモデルをブラッシュアップしていく方針はかなり作図しやすい

• 確認事項等を赤字で書き出しておくと、後からタスクが切るときに助かる

• ドメインモデルズで多重度や日本語や英語の対訳を定義しておくと、コーディングしやすそうな雰囲気

• ソースコードがドメインモデルの変更にに対して、柔軟に対応するべきなのはもちろんとして、ドメインモデルを定義しているドキュメントも変更しやすさやメンテナンスしやすさが大事なのだなと気づけた。
  コーディングしていてドメインモデルを変更する必要があるときも、図で管理していると変更しやすいため、コードとドメインモデルの乖離を防ぎやすそうな気がする

あとがき

3時間程度の長尺動画でしたが、楽しく閲覧させていただきました。コメント欄の質問や指摘も興味深い物が多かったです。
次回は今回モデリングしたドメインモデルをもとにコーディングしてみようと思います。
ここまで見ていただきありがとうございました！