本日発売された @masuda220 さんの「現場で役立つシステム設計の原則」が気になってる方へ。
紙の本。
こっちは
kindle。
まだ全部読めてないけれど、精読するといつ読み終わるかわからない・・・。
なので、まったく読んでない気分になって目次ベースで紹介してみます。
どう言うことが書いてそうかの参考にはなるかなと。
しかしこの内容、よくこのサイズの本で、それほど小さくない字なのに入りましたね。要約力のなせる技なんでしょうか。
目次流し: 期待とつまみ食い
目次をさらっと読んで、こんなこと書いてるのかなーって妄想を交えて書き連ねます。たまに実際開いて。
なお、 「太文字のカギカッコ」 は目次からの引用です。
Chapter1 小さくまとめてわかりやすくする
ソフトウェアはソフトなのに変更が大変になるのはなぜだろう。
これには大きくしてしまった時点で負けと言う原則がある。
大きくせざるをえないものがないとは言わないけれど、小さくする、小さく保つ努力を怠っていい理由にはならない。
このChapterでは小さくあるためにどのようにするかが書かれていそうな雰囲気。
難しい言葉で言えば高凝集で疎結合なのだが、抽象的な話に逸れがちなテーマ。
これに対してメソッドやクラスを作成する上での一般指針や、ファーストクラスコレクションをあげているので、抽象ではなく具象で語っているのだろう。
Chapter2 場合分けのロジックを整理する
組み合わせられるように作成できるのはソフトウェアの強みではある。
一方で簡単に組み合わせ爆発を起こしてしまい、気づいたら制御できなくなっているものである。
C2カバレッジが現実的でないと言われたりする話もある。
このChapterでは、組み合わせを発生させないためにできることを詰め込んでいるようだ。
そんな何でもかんでも組み合わせる必要はない、こうすれば余計な複雑性を放置せず済む、と区分や種別の引力に対峙している。
また、本書はJavaを使っているため、強力な機能であるenumの実践も記述されている。
私自身、増田さんと仕事をさせていただいた時に「enumをそう使えばいいのか!」とショックを受けた。
その内容はわずか2ページにエッセンスが詰め込まれているのだが、このChapterだけでなく前Chapterも理解して身についていなければ、単に「ふーん」で読み流してしまう。
Chapter3 業務ロジックをわかりやすく整理する
神クラスが生まれるのはなぜだろう。
他言語にあるプロパティ構文やLombokが欲しくなるような、getter/setterだけを持っているクラスに何の価値があるだろう。
余計な複雑性を持ち込んでいるんじゃないか。
データとロジックが同じ場所にあることがカプセル化だったんじゃないか。
あれはただの教科書的なもので、実務では使えない机上の空論なんだろうか。
・・・なんて話に真っ向勝負を挑んでいるのが、このChapterの見出しを眺めた印象である。
重要なのは、ここで記載されていることが全て実際のシステムからの知見であること。
また、海の向こうの関わりが少ないものではなく、日本のシステム開発で実践されたことであることかもしれない。
文化が違うから実現できるんだ、ウチではそういうのはできないんだ、なんて言い訳をいつまでも続けるのは難しい気がする。
Chapter4 ドメインモデルの考え方で設計する
増田亨と言えばDDDの人と認識されている方も結構いるはず。
DDDは「エリック・エヴァンスのドメイン駆動設計」が有名で、本書が登場してからよく聞くようになった言葉である。
とは言え「DDD=エリック・エヴァンスのドメイン駆動設計」でもなく、増田さんは増田さんのDDDを実践していると思っている。
つまるところ、このChapterは「増田亨のドメイン駆動設計」なんだろうなーと。
見出しを眺めると、エヴァンスの言葉はほとんど使われておらず、むしろ「コト」などの聞き慣れた言葉が使われている。
どう解釈するか、などに悩まずに素直に内容と向き合えるのじゃないかなと。
そして教科書的に済まないのが本書の特徴。
前半で一通り説明したのち、最後 「業務の理解がドメインモデルを洗練させる」 では 「形式的な資料はかえって危険」「言葉のあいまいさを具体的にする工夫」 など、現場で向き合ったこともあります。
現在進行形で取っ組み合いしてるところなので重点的に読みたい。
Chapter5 アプリケーションの機能を組み立てる
サービスクラスを作ると、ドメインモデルの責務がサービス側にうっかり漏れ出して、ドメインモデルが空洞化するなんて話はよく聞くところで。
また、業務システムはデータベースありきな文化も強くあります。
これらの慣習的な作り方の引力への抗い方について書かれてそうな感じがします。
「初期のドメインモデルは力不足」 と言うまぎれもない事実を事実として認め、それからどうするか。
決して"最初から完璧なドメインモデルを作ろう"ではないはず。
Chapter6 データベースの設計とドメインオブジェクト
データベースに関わるよくある問題と、テーブル設計の一般則、そして工夫と言う感じで書かれているようだ。
問題点などはSQLアンチパターンとも絡むのかな(参考書籍にもあげられてるし)
「参照をわかりやすくする工夫」 のところでは、当然のようにイミュータブルデータモデルや、結果整合性が書かれている感じがする。
そしてChapter5でデータベースに引っ張られないようにと説明していたはずが、ここで 「オブジェクトとテーブルは似てくる」 と言われてしまい、え?となっているところに 「オブジェクトはオブジェクトらしく、テーブルはテーブルらしく」 と続けてくるのは面白い。
Chapter7 画面とドメインオブジェクトの設計を連動させる
DDDで捉えたつもりのドメインモデルと、画面の要件がズレていることは珍しくない。
そこには色々な関心ごとが混じり合っているから。
画面向けのドメインと実際のドメインが別にあり、それらが複雑に絡み合っているんじゃないか、なんて考えたこともあるのだけれど、そんなことをしているとシステムを作るのに莫大なコストがかかることになってしまうので、違うんじゃないかなーとか思ってた。
このChapterでは 「画面とドメインオブジェクトと連動させる」 として、画面都合のロジックをどのようにしてドメインオブジェクトに記述しつつ、ドメインオブジェクトの独立性を維持するのかが書かれてそう。
なおWebアプリケーションの画面なのでHTMLが前提になってます。
Chapter8 アプリケーション間の連携
流行り?のマイクロサービス的な話がはいってるのかなーと眺めてみたけれど、そのような記述はないです。
ここでの連携は素直にアプリケーション間の連携で、対象はファイル転送、データベース共有、Web API、(非同期)メッセージングを指しています。
その中でも特にWeb APIに重点が置かれているようで、7割くらいはWeb APIの話っぽい。
Chapter9 オブジェクト指向の開発のプロセス
ここで開発プロセスの話に飛ぶのか。
開発プロセスのソフトウェアに対する影響などの一般則から、 「ソースコードを第一級のドキュメントとして活用する」 の転換。
そして 「更新すべきドキュメント」 として、現実で必要になるソースコード以外のドキュメントの話。
決してドキュメントは全て不要!なんて言ってないのがわかる。
なぜ開発プロセスの話になるんだろうと思ったので少し先読みしたところ、どうやらプロセスを変えないとオブジェクト指向の開発はできないようなことが書いてそう。
初期のドメインモデルが力不足なのだから、当然と言えば当然で、それを通すためにはプロセスも当然あったようにしないとね。
リファクタリングやオブジェクト指向エクササイズなどなどの話。
これだけで一冊書けるところですが、車輪の再発明ではなく、主に本の紹介で構成されてるChapterです。
全体通して
本を受け取った時は、あれ、本小さくね?軽くね??って思いました。
こうしていざ目次を見てみると、思った以上に広い。そして深い。びっくりした。
タイトルの「現場で役立つ」ですが、実際役立てるかは読んだ方ご自身の責務です。
あたりまえですが、読んでも使わないと役に立ちません。装備しないとダメとかそう言うやつです。
あと参考文献のページに書影入ってるのが地味にいいですね。
対象読者層
読みやすい文で、分量は多くなく、コードや図は多め。
そしてそれほど高くなく、このカバー範囲。
「システム設計の原則」と言うと身構えるかもしれないけれど、新人から少し脱したくらいから読んでもいいんじゃないかなと思います。
おそらく、難しくて全く理解できないなんてことにはならない。
一方、書いている内容の理解の仕方は、背景の知識の広さや深さで大きく変わる印象を受けました。
どのChapterをとっても、完全に理解していて何も得るものがない、なんてことはそう無いでしょう。
そのため、システムを開発するあらゆる方に読んで貰いたいと思いました。
現場でもこの本を読んでる前提で、どうしようって話ができると楽しそう。
読書会とかするといいんじゃないかなー
対象読者が幅広くて、コンテキストによって理解の仕方が変わりそうなので、持ち寄って「自分はこう読んだ」なんて話をすると面白いんじゃないかなーと。
と言うのも、平易な文でボリュームが少ないので、さらっと読んでしまおうと思えばそれで終われるんです。
でもそうしちゃうにはちょっともったいない感じもする。
ネタ: タイトルについて
「現場で役立つシステム設計の原則」なんですが、増田さんの会社名って「システム設計」なんですよね。。。
なので、会社名が他のだったら、 現場で役立つXXXの原則 (XXXは任意の会社名)となったのだろうか、とかなんとか。
いや、どうでもいいんですが。