社内の輪読会でモデリングについてまとめたので、自分用にQiitaにも残しておきます。
モデルとは
システム
目的達成のための手段。
モデル
動作原理やしくみを簡単に理解・説明するために、物事の特徴や関係性を図式化したもの。
モデルはシステムの構成要素であり、目的達成手段の一部。
モデリング
モデルをつくる活動。
現実世界での物理的な存在と、情報システム上のモデルが1対1になるとは限らず、1対多の関係になるケースがある。
モデリングする時に大切な考え方
モデルは物ではなく目的達成手段
目的駆動で名前設計することが、適切に目的達成するモデルを設計することにつながる。
単一責任とは単一目的
クラスが果たす目的は、たったひとつに限定すべき。
クラスを特定の目的に特化して設計することで、変更に強い高品質な構造になる
モデルの見直し方
- そのモデルが達成しようとしている目的をすべて洗い出す
- 目的それぞれ特化したモデリングをし直す
- 目的駆動名前設計にもとづき、モデルに命名する
- モデルに目的外の要素が入り込んでいる場合、さらに見直す
【悪い例】なんでも詰め込まれた神商品モデル
【良い例】目的ごとにモデリングした商品モデル
深いモデル
モデルを目的達成手段として解釈し、抽象化すると、モデルに発展性が生まれる
本質的課題を解決し、機能性の革新に貢献するモデルを、ドメイン駆動設計では深いモデルと呼ぶ
モデリングする時のポイント
- モデリングする段階では具体は置いておいて、抽象的に作った方が上手くいく
- モデリングは実際に手を動かして作ってみないと上手くならない
UML（Unified Modeling Language 統一モデリング言語）
モデリングする時、モデルの見直しをする時にUMLが役立ちます。自分の考えを整理したり、チームメンバーとモデルを議論する際に、視覚的に図で整理してある方がよりわかりやすいです。
UMLにはいろいろな種類がありますが、代表的なものを3つご紹介します。
クラス図
クラスの構造や関係を表すもっとも代表的な図
関係性（線）の意味:
- --> (矢印): あるクラスが別のクラスを知っている（参照している）
- *-- (黒菱形): 「全体」と「部分」の関係（コンポジション）。注文が消えれば、それに紐づく注文明細も存在意義を失うような強い結びつきを表します
多重度（数字）: 1 対 *（多）など、数の関係性を定義します。
ユースケース図
「システムができること（機能）」と「誰がそれを使うか（アクター）」の関係を表します。 システムの機能要件を俯瞰するのに適しています。
- アクター（人型）: システムを利用するユーザーや、連携する外部システムを表します
- 枠（パッケージ）: システムの境界線（ここからここまでがシステム化の範囲）を表します
シーケンス図
処理の流れを「時間軸」に沿って表した図です。 オブジェクト間でどのようなメッセージ（データのやり取り）が行われるかを可視化します。
例：購入ボタンを押してから注文が完了するまで
- ライフライン（点線）: 時間の流れ（上から下へ）を表します。
- Alt（代替フロー）: 「在庫がある場合」と「ない場合」のような条件分岐を表現できます。
まとめ
小さなとりあえず動くシステムを作るだけであれば、設計やモデリングについて深く考えなくても問題ありません。けれど、大きなプログラムとして長い期間開発していこうと思うと、開発する段階でモデリングを行ったり、途中でモデルの見直しをしていかないと、一部の変更で依存している他の機能の不具合が起こったり、可読性が低いスパゲティコードになってしまったりということに繋がります。
今回の記事には、モデリングの本当に基礎的なところしか書かれていませんが、より深くてわかりやすい記事や書籍が世の中にはたくさんあるので、興味を持った方は調べてみてください！
参考文献