ドメイン駆動設計の練習！！モデリング編

はじめに

データベーススペシャリストの過去問(2021年秋午後Iの問１)を例に、

ドメイン駆動設計でモデリングの練習をしたのでまとめました。

モデリングをしてみて感じたことや気付きなどについて本記事には書いていますが、

これをベースにサンプルコードやテストコードなども書いてみたので、

その辺りについても今後別の記事にまとめていきます。

2022/03/22追記

ドメイン駆動設計でモデリング〜コーディング〜テストコード作成

までのまとめ記事を作ったので興味がある方は是非みてください。

ドメイン駆動設計の練習！！モデリング〜サンプルプログラム・テストコード作成(まとめ記事)

ドメイン駆動設計の目的について

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

ドメイン駆動設計 サンプルコード&FAQ(松岡 幸一郎)

ドメイン駆動設計の目的について本では述べられていました。

ソフトウェアはそもそもある問題や課題を解決するために作られる。

この問題領域や課題領域のことをドメインと呼び、

ドメイン駆動設計は実際にこの問題や課題に悩んでいる人やその領域に詳しい人(ドメインエキスパート)

と一緒にドメインモデリングを行うため、

開発者だけでソフトウェア開発を進めるよりも、

実際の問題や課題を正しく把握して本当に求められているモノ(機能性の高いモノ)ができる可能性が高まる。

という考え方です。

また、

ドメイン駆動設計では、ドメインモデリングの結果をそのまま実装に落とし込むことができ、

頻繁な変更に耐えられるような実装パターンを用います。

そのパターンにエンティティやリポジトリなどがあります。

頻繁な変更に耐えられなければならないので、ドメイン駆動設計においてテストコードは重要になります。

ドメイン駆動設計で自分が行ったモデリング

モデリング結果は以下にまとめました

＞＞モデリング結果(drawio)

モデリング対象にしたのはデータベーススペシャリスト過去問です

＞＞モデリング対象(データベーススペシャリスト2021秋午後I問1)

ポイントシステムのテーブル設計が題材の問題なのですが、

(一部妄想して)ポイントシステムがAPIを用意しておいて加盟店のECサイトが商品を購入する際、

このAPIを叩いて支払情報を登録。それに対してポイントをバッチ処理で付与する。

そんなイメージのお題にしてみました。

この辺りは、作成したシステム関連図とユースケース図を見ればざっくりと分かります。

システム関連図でシステム間やシステム利用者との関係性が整理でき、

ユースケース図の方ではポイントシステムの振る舞いが整理できました。

(今回はECサイトからAPI連携された支払情報を登録するところにフォーカスしています)

次に、オブジェクト図を作成していきました。

支払情報として具体的な値を利用しながら、データベーススペシャリストの過去問を見ながら整理していきました。

(ルールや制約といったドメインで表現すべき知識が少なかったので一部妄想で付け足したりしています)

例えば、

支払の際に支払う金額を複数の決済手段を組み合わせて支払えたり(支払い手段方法によってポイント率が違う)

などが表現できるようにオブジェクト図を作成していきました。

また、オブジェクト図は上の例でいうと複数手段の組み合わせで支払うケースもあれば、

１つの決済手段だけで支払うこともできるので２パターンのオブジェクト図を作成しました。

ここまできたら、最後は

ドメインモデル図を作成していきます。

各オブジェクト同士がどういった多重度でどう関連し、オブジェクトはどんな属性を持つべきで、

どんなルールや制約を持つのか？？をそれぞれ図で表現していきました。

オブジェクト図の具体例があれば、ドメインモデル図で抽象化していくことは比較的簡単に行えます。

例えば今回挙げた例だと、

支払で0円というのは取り扱わないとの、1,000,000以上の金額は取り扱わないというルールを決めました。

また、オブジェクト間の多重度の例で言うと、

支払があるのに支払方法明細(支払う決済手段はなし)というケースはあり得ないのでその辺りは多重度で表現しました。

最後に集約について考えました。

集約は必ずセットで取り扱う単位で、

セットでデータベースに登録されるし、セットでデータベースから再構築されます。

今回で言うと、支払オブジェクトは支払明細、支払方法明細と必ずセットで

存在するのでこれらセットで取り扱うことにしました。

ユーザともセットにすべきか悩みましたが、

ユーザは今後別集約に入れたかったのと、

支払と支払明細との関係よりは緩くていいかなと言うなんとなくの理由でこうしました。

(あるべき姿や正解は今後進めながらブラッシュアップしていければと)

ここまでがざっくりモデリングで実施した内容になります。

モデリングすることのメリットとやってみての感想や気付き

僕は、ドメイン駆動設計の本はエバンス本、

松岡さんのモデリング/実装ガイド、サンプルコード&FAQ、

成瀬さんのドメイン駆動設計入門などなど今まで読んできたので知識としてはある程度あるつもりでしたが、

実際に手を動かそうと思うと全く最初動きませんでした。

手が動かなくなる度に、本を読み直して不安なままモデリングを進めていきました。

特にモデリングは実践してみて初めて自分の理解度が足りていないことを実感できたり、

ER図に慣れているクセが出て混乱したり・・・などに気づけたので、分かりやすく解説されているからといって、

本を読んだだけで終わるのではなく、実際に手を動かすところまですべきだなと改めて感じました。

モデリング/実装ガイド、サンプルコード&FAQで紹介されていたモデリングの手順を踏むと、

特にオブジェクト図で具体例を挙げてからドメインモデル図をかくのでスムーズにモデリングが進められたり、

多重度をかけたりするのは実感できました。

システム関連図やユースケース図は特に現場で新規参入者が最初に見せると

キャッチアップが早いだろうなと思いました。

オブジェクト図なら、ドメインエキスパートもイメージが付きやすいので一緒にモデリングができて、

間違った方向に行って、指摘されて軌道修正してというような無駄な工数が削減できそうなのと、

さらに、ルールや制約なども記載したドメインモデル図をソースコードにきれいにマップすることができれば、

あちこちに同じルールや制約が散らばってしまうこともなく、

変更時の影響範囲も特定しやすくなりそうです。

ただ僕が直近やってた案件だと、

性能めちゃくちゃ求められるけどルールや制約が比較的シンプルなCRUDのみオンラインシステム

(逆にバッチは複雑だけどこちらも性能求められるのでプロシージャ利用するしかない)

みたいな感じだったので・・・ドメイン駆動設計は採用できず。。。でした