本の基本情報
本の基本情報について紹介する。
本の目次
以下は本書の目次です。
- Chapter1 小さくまとめてわかりやすくする
- Chapter2 場合分けのロジックを整理する
- Chapter3 業務ロジックをわかりやすく整理する
- Chapter4 ドメインモデルの考え方で設計する
- Chapter5 アプリケーション機能を組み立てる
- Chapter6 データベースの設計とドメインオブジェクト
- Chapter7 画面とドメインオブジェクトの設計を連動させる
- Chapter8 アプリケーション間の連携
- Chapter9 オブジェクト指向の開発プロセス
- Chapter10 オブジェクト指向設計の学び方と教え方
概要
Chapter1 小さくまとめてわかりやすくする
タイトル通り、小さくまとめてわかりやすくするためのテクニックが紹介されている。
この章のテクニックは、マーチンファウラーの「リファクタリング」にも書かれているものが多いので、知っている人もいるだろう。 改めて、今回復習することができた。特にオブジェクトは、自分も含めて作らない人（知らない人）が多いと思う。 自分はC言語とC++をメインに使ってきたので、毎回インスタンスを返す考えがなかった。（ガベージコレクションがない = newしたらdeleteしないといけないため） 今後、PythonやJavaを使っていくことになりそうなので、これを知れるだけでもこの本を読む価値があった。
コレクションオブジェクト/ファーストクラスコレクションは、初めて聞いた。コレクション操作の結果を同じ型のコレクションオブジェクトを作って返すことは、ガベージコレクションがない言語を使ってきた自分にとっては、違和感しかなかった。 しかし、不変にするという考え方を知る/知らないでクラス設計に大きく差ができるとも感じた。早いうちに知ることができてよかった。
Chapter2 場合分けのロジックを整理する
ガード節などでelse節を無くす、ポリモーフィズムでif/switch分を無くすなどの話は、有名なので知っていた。
しかし、Javaのenumで状態遷移をうまく表現できる話は全く知らなかった。Java使う人には参考になるだろうが、他の言語使う人はできるか怪しい内容。
Chapter3 業務ロジックをわかりやすく整理する
Chapter2まではオブジェクト指向のテクニックが多かったが、この章辺りからドメイン駆動設計という言葉は出ていないけれど考え方を説明している。
３層アーキテクチャ（プレゼンテーション層、アプリケーション層、データソース層）＋ドメイン（業務ロジック）で関心事を分かりやすく分離しようといった内容を説明している。
Chapter4 ドメインモデルの考え方で設計する
ドメイン駆動設計を基に、ドメインモデルをどう設計するか説明している。
- 小さい部品（機能分割して定義した下位クラス）から作っていき、それを業務ロジックと合わせて組み合わせていく
- コト（予約、注文、支払、出荷などの事象）に注目して関係を整理する
- 業務の理解がドメインモデルを洗練させる
上記あたりは参考になった。特に、自分はモデリングがうまくできないので、コトに注目するという具体例があったのは良かった。
しかし、実際に手を動かして作ってはいないので、自分で作ってみて自分の中に落とし込む必要があると感じた。
Chapter5 アプリケーション機能を組み立てる
アプリケーション層の説明。アプリケーション層に業務ロジックを書いてしまいがちだが、アプリケーション層の役割は進行役であり調整役。
さまざまな関心事の交差点になり、ごちゃごちゃしやすい。逆に言えば、アプリケーション層をシンプルに保つことで、システム全体が見通しが良くなり、変更のやりやすさにつながる。
Chapter6 データベースの設計とドメインオブジェクト
データソース層の話。データベースについて自分はあまり詳しくないので、ここはかなり難しかった。
良いテーブル設計の話があるが、まずテーブル設計をしたことがないので、実際にデータベース弄るようになったらもう一度読み直したい。
Chapter7 画面とドメインオブジェクトの設計を連動させる
プレゼンテーション層の話。画面と一致させるという話が多かった印象。
画面の関心事を小さく分けて独立させるなど参考になる部分は多かった。 自分はVue.jsでフロントを描くことが多いが、.vueファイルに業務ロジックを書くことが多かった。 今後、業務ロジックは分離させてドメインである.jsファイルからインポートさせていくのが良いんだなと理解した。
Chapter8 アプリケーション間の連携
WebAPIも小さくした方が利用しやすい。 他にもWebAPIのなぜPUTやDELETEではなく、GET, POSTを使った方が良いの説明などもあった。
Chapter9 オブジェクト指向の開発プロセス
ドメインモデルのソースコードには、業務の用語、業務の知識を反映しているので、分析と設計が一致していればドキュメントは不要という話が印象的だった。ドキュメント不要論に関しては自分は懐疑的だが、確かに無駄と思う部分も多い。
著者も全部不要と言っているわけではなく、「利用者向けのドキュメント」「画面や帳票」「データベースのテーブル名/カラム名とコメント」
また、全体を俯瞰するドキュメントとして、「システム企画書やプロジェクト計画書のシステム概要説明」「プレスリリース」「リリースノート」「利用者ガイドの導入部」は必要と言っている。
いかにコードに書いていない情報を共有するのかが重要になってくると感じた。
Chapter10 オブジェクト指向設計の学び方と教え方
おすすめの書籍がいくつか紹介されている。
紹介されているマーチンファウラーの「リファクタリング」は、自分も読んだことがあり、評価も高いのでおすすめです。
最後に
Javaで書かれていると言われてたので、ちょっと抵抗があったがコードもそんなに多くなく、オブジェクト指向入門しているレベルの人なら理解できると思う。 コードは補足であり、本文で十分理解できる内容だった。
chapter7のドキュメントは不要というのには懐疑的だが、全体的に参考になるし、DDD(ドメイン駆動設計)の入門書として良い本だった。 自分はドメイン駆動設計を先に読んでいたが、難しく理解できない部分も分かりやすく説明されていた。 しかし、自分の中に落とし込めていないところも多くあるので、そこは実践を通して身につけていく必要があると感じた。
自分がいかにドメイン駆動設計をしても、他の人が崩してしまっては全く意味がなくなるので、ドメインモデル設計の共有が一番難しいと感じた。 業務後に勉強する人は数少ないので、議論を重ねて知識を共有する必要がある。そのためにはドキュメントが必要な気がしている。
P.S.
新しく作る時はドメイン駆動設計を導入しやすいが、業務の多くはすでに出来上がっているシステムの機能開発がメインである。 すでに規模が大きくなっているので、途中からドメイン駆動設計の考えをチームメンバーに共有して、地道に改良していくのはなかなか大変だなと思っている。
どうすれば良いのか、参考になる事例があれば教えて欲しいです。
