はじめに
こんばんは。
現在 現場で役立つシステム設計の原則 という本を読んでおります。
過去に1度読んだことがあったのですが、その際はザーッと読んだだけなのと、ほぼほぼ内容忘れてるので読み直しております。
1〜4章まで読んだので、それを読んで感じたことを残しておきます。
本題
1 章 小さくまとめてわかりやすくつくる
どのようにプログラムが複雑になっていくか、どのようにすれば、複雑さを回避できるかなどの簡単な説明が書いてありました。
本に書かれているコードも、そのコードに対して、どうしてこのようなコードだと良いのかという説明も、エンジニア初心者の方でもとてもわかり易いものでした。
プログラムの修正に3日かかるか、それとも半日で済むか。その違いを生むのが「設計」なのです。
という文には、ハッとさせられます。
2 章 場面分けのロジックを整理する
1章と同様にとてもわかり易いコードと説明で、場面・区分毎の複雑さを生まない設計を説明されていました。
1章との違いは、 interface を使用したより具体的な状況での設計を説明されています。
3 章 業務ロジックをわかりやすく整理する
前半は、コードの見通しが悪くなる原因が説明されています。
複数ある原因の中で個人的に読んでて面白かったのは、原因の一つとしてあげられている 共通機能ライブラリ の話でした。
初級者のときによく作ってしまう commonとかutilとかのライブラリですが、そこまでうまく運用できないよというのが例とともにわかりやすく説明されていました。
後半は、その対処法が説明されています。
主たる原因となるデータクラスと機能クラスを分ける手続き型の設計ではない別の考え方を示してくれています。
また、その設計のやり方を簡単に説明してくれています。
個人的にはこの章で出てきた以下の文がとても気分を楽にしてくれました。
オブジェクト指向の設計は、改善の繰り返しです。最初から良い設計が見つかるわけではありません。 コードを書いて動かしてみながら、ロジックの置き場所やクラス名/メソッド名の改善を続け、より良い設計を見つけていくのが、オブジェクト指向設計の基本です。
もちろんベースラインはありますが、最初からきれいなものは作れないんだよということは、心の余裕になります...w
4 章 ドメインモデルの考え方を設計する
3章の後半で説明されたコードの見通し悪化の解決策であるドメインモデルの考え方が詳細に説明されていました。
4章はだいぶ今までの章と比べてページ数も多くなっています。
なので更に分けて、感想を残しておこうと思います。
1. ドメインモデルの考え方を理解する
ドメインモデルはプログラミング言語で書いた「業務の用語集」であり「業務の説明書」です。ただし、単なる用語の羅列ではありません。それぞれの用語がどのように関連し、どのように相互に作用するかをパッケージ構成やクラスの参照関係で立体的に表現する手段です。
序盤に説明してくれているこの文書が一番なるほどときたところでした。
また、上記を実現するために、
- 要求の聞き取り
- 不明点を確かめるための会話
- 図や表を使っての整理
- 理解した結果を記録するための文書の作成
など、実際にプログラムを書く以外の行動が大事になってくるということです。
この辺は1, 2までをやってる人が多そうだなと思いました(自分は余裕があれば3までやるけど、大体2で終わっちゃうかも...)
詳細の聞き取りの後は、コードに落とし込むための思考(設計)を行います。
このときプログラム = 業務の説明となるためには、業務に使っている用語をクラス名にするということが有効のようです。
抽象的になりすぎないなるべく具体的な名前を採用するべきです。そのために最初の聞き取りが重要ということです。
データモデルとドメインモデルの違いにも触れています。
データを中心に捉えたデータモデルと、業務の関心事を中心に捉えたドメインモデルで、どのように考え方が違うか、どのような設計になってくるかを例とともに紹介しています。
2. ドメインモデルをどうやって作っていくか
パッケージ図 や 業務フロー図 などの図の説明と、それを利用したドメインモデルの作成方法が説明されています。
大事なのは 重要な部分から作っていく ところです。
重要な部分を見つける手段として上記の図が役に立つという感じです。
また特に重要だったのは ドメインオブジェクトを機能の一部として設計しない ということでした。
ある機能の一つとして作ってしまうと、それに関連する機能との依存が生まれてしまい、その機能の部品となってしまいます。
そうなってしまうと、もし修正が配流となった場合、調査・対応する影響範囲が広がってしまいます。
重要なのは以下。
どうやって機能を実現するかに注目するのではなく、ある特定の業務のデータとそのデータを使った判断/加工/処理の業務ロジックだけを切り出した独立したロジックを作ります。
3. ドメインオブジェクトの見つけ方
ドメインオブジェクトをみつけるために ヒト・モノ・コト に注目するということが説明されています。
何らかの商品の販売活動を例に詳細な説明をなされています。
4. 業務の関心事の基本パターンを覚えておく
基本となる4つのドメインオブジェクトと、4つの関心事のパターンを使って整理していくと、業務ロジックはアプリケーション側ではなくドメインモデル側に集まるようになるとされています。
また、それぞれの関心事のパターンの詳細が説明されています。
5. ドメインオブジェクトの設計を段階的に改善する
初期段階で設計したドメインオブジェクトを修正しなければいけなくなった際の対処方法が説明されています。
クラス名やドメソッド名の変更やロジックの移動、また、取りまとめ役のクラスの導入などです。
取りまとめ役のクラス = 最小単位の値オブジェクトを複数持ち扱いやすくしたクラスと言う意味です。
6. 業務の理解がドメインモデルを洗練させる
ドメインモデルの成長のために開発者自身の業務知識を増やすことが説明されています。
重要なのは、全てを理解することではなく 重要な言葉とそうではない言葉を理解すること と 言葉と言葉の関係性を見つけられること だそうです。
そのための方法として、その業務のエキスパートへのヒヤリングや、ヒヤリング結果の可視化を行うことが重要です。
また、手ぶらでヒヤリングしても十分な聞き取りが出来ない可能性もあり、その状況では業務知識は乏しいままになり、ドメインモデルの設計ができないままになってしまいます。そのためにはある程度対象業務の基礎知識を身につけるべきとも書かれていました。
具体的には業務マニュアルを読んだり、実際に画面をざっと触ってみたりなど、自分でできる範囲の箇所です。
終わりに
3年前くらいに読んだのですが、全く覚えてなかったですw
個人的には4-4の 業務の関心事の基本パターンを覚えておく はとても具体的にかつわかりやすく書かれていて、とても読み応えがありました。
実際にいまお仕事しているプログラムに当てはめて考えたりして、その時の思考が楽しかったです。
次は5〜7章を読みます。
現場からは以上です。
