こんにちは。
今回は、DDD（ドメイン駆動設計）を学ぶために、勤めている会社で話題になっていた「現場で役立つシステム設計の原則」を読みました。
学ぶことが多く、今後も定期的に見返したいと思ったので、ポイントをまとめました。
設計の重要性
- どこに何が書いてあるかを分かりやすくし、修正や拡張が楽なコードを生み出すこと
- 変更が大変なプログラムの特徴 3点。どれも関心事の詰め込みすぎが原因
-
-
メソッドが長い
-
クラスが大きい
-
引数が多い
-
設計の仕方の比較
2つの設計の仕方を比較します。
どちらの設計も、関心事の分離のために 3層アーキテクチャ を使うことを前提にしています。
- プレゼンテーション層：UIなどの外部との入出力
- アプリケーション層：業務機能のマクロな手順
- データソース層：データベースとの入出力
データクラスを使う設計
- 従来の手続き型の設計で基本とされていた、データを格納するデータクラスと、ロジックを記述する機能クラスに分ける設計
- データクラスは getter/setterメソッドだけを持ち、データを使った判断/加工/計算のロジックは、機能クラスに記述する
- 3層が同じデータクラスを参照できる結果、データクラスを使うロジックが3層のどこでも書けてしまい、重複しやすくなってしまう欠点があった
ドメインモデルを使う設計
- 業務ロジックを記載するのはドメインモデルのみとすることで、3層の記述は簡潔で分かりやすくなる。業務アプリケーションのコードが複雑になる理由は、業務ロジックの複雑さであるため
ドメインモデル設計の仕方
ドメインモデルを使う設計の利点を理解した後は、実際にどのように設計を行うかを学びます
- ドメインモデルの設計は、業務で使われる具体的な用語（概念）を手がかりに進める。その用語が、データとロジックをひとかたまりとしてプログラミング単位として使えるかを検証する
- 部分に注目し、個々の部品を作り、それを組み合わせて段階的に全体を作っていくボトムアップのアプローチを取る
- 部分に注目するが、全体像を意識しないと間違った方向へ進む危険がある。全体を俯瞰する道具として、以下の2つがある
-
- パッケージ図
-
パッケージ間の依存関係を表現する
-
- パッケージ図
-
- 業務フロー図
-
業務の活動を時間軸に沿って図示したもの
-
顧客/販売部門/出荷部門などの活動の主体ごとのレーンを並べ、その間の情報のやり取りを表現する
-
- 業務フロー図
- これらの図で全体を俯瞰したら、重要な部分を探し、重要な部分から作っていく
- 業務を分析し、理解するために、業務の関心事をヒト/モノ/コトの3つに分類する手法がある
-
- ヒト：人の意思/判断/行動についてのデータを持ち、そのデータを使った判断/加工/計算のロジックを持つ
-
- モノ：ヒトが業務を遂行するときの関心の対象。これらの属性を表現するデータと、そのデータに対して業務的にどういう判断/加工/計算をしたいかをロジックとして持つ
-
- コト：基本的にヒトの意思決定や行動の結果。業務アプリケーションの基本的な関心事は、コトを記録して、コトの発生を通知すること。コトに注目すると、全体の関係整理しやすい
ドメインモデル設計の注意点
- 業務では実際に使っていない抽象的な言葉をクラス名として使ってしまうと、そのクラス名は具体的には何も説明しておらず、業務を的確に捉えられない
- オブジェクトとテーブルを自動的にマッピングするアプローチは、どちらかの設計のアプローチの制約を受け、うまくいかないことが多い。業務ロジックはオブジェクトで、事実の記録はテーブルで行うべき
- 表示のためのロジックと業務ロジックを混在させない
-
- 例1）一定金額を超え、かつ、注文後1日以上経過した注文を画面で強調表示する場合、画面表示のロジックに if 文を書いてしまうことがあるが、これは業務ルールなのでここに書かない方が良い
おわりに
ここまで読んでいただきありがとうございます。
これまで DDD（ドメイン駆動設計）の本を何冊か読んできましたが、個人的には本書が一番理解しやすかったです。本書をとっかかりにして、関連書籍を読んでいき、実践することで DDD への理解を深めていこうと思います。
本書の中では、図を多く使って丁寧に説明されていて理解しやすかったので、ご興味ある方は是非読んでみてください。
