「現場で役立つシステム設計の原則」を読んだ
Posted on 2017-08-08
現場で役立つシステム設計の原則 / 増田亨著を読んだので感想を書く。
総評
設計について書籍はたくさんがあるが、その入門書としてよさそうだと感じた。 リファクタリング、DDDなどのエッセンスが平易な言葉でまとめられている。
概要と感想
Chapter1. 小さくまとめてわかりやすくする
- 変数や関数の名前づけなど、コードレベルの話。
- Martin Fowler著のリファクタリングに書いてあるような内容が多かった。
Chapter2. 場合分けのロジックを整理する
- if文が増えるとどうしてもコードの見通しが悪くなるので、整理するための方法が書かれていた。
- 普段Ruby on Railsを使っているので、型がほしいという感想しかなかった。
- dry-typesを使えばなんとかなったりするのだろうか。
Chapter3. 業務ロジックをわかりやすく整理する
- いわゆるドメインモデル貧血症にならないように、データとロジックをまとめてオブジェクトとして扱いましょう、ということが書かれていた。
- オブジェクト指向設計実践ガイドにも通じる話だが、形だけオブジェクトクラスを作って、手続き型で書いてしまうのはなんちゃってOOPなので気をつけたい。
Chapter4. ドメインモデルの考え方で設計する
- このあたりからDDD的な話になってくる。
- 業務の関心事をまとめてドメインモデルとする。最初から業務の関心事をまとめるのはむずかしいのでイテレーティブに洗練させていく。
- 感想としては、イテレーティブにリファクタリングするには、テストなどリグレッションを検知する仕組みが必須だなと感じた。
Chapter5. アプリケーション機能を組み立てる
- 3層+ドメインモデルでアプリケーション層について書かれていた。
- 自分の経験上もサービスはドメインの知識が浸出してきてドメインモデル貧血症になりがちなので、注意したい。
Chapter6. データベースの設計とドメインオブジェクト
- テーブル設計や、参照を使うことについて書かれていた。
- NULLはあまりよくないとわかっていても手軽さのためについついたくさんのカラムをもつテーブルを作りがちなので、改めて注意したい。
- UPDATEいらない説もよく聞くが、実際やろうとすると結構大変なイメージがある(やったことはない)。
Chapter7. 画面とドメインオブジェクトの設計を連動させる
- 画面とドメインオブジェクトの付き合い方についてかかれていた。
- 画面にひきずられてドメインオブジェクトが煩雑になるのはよくない。どうしたらいいか。
- ここでは、画面そのものをドメインオブジェクトにあわせて簡単にする方法が主張されていた。
- たしかにその通りで、次に画面の構成を検討する機会があれば、検討事項にいれておくべき項目だと感じた。
Chapter8. アプリケーション間の連携
- 主にWeb API設計についてかかれた
- いわゆるRESTfulなAPIに近い設計のようだった。
- 最近だとGraphQLをよく聞くが、ここでは触れられていたなかった。
Chapter9. オブジェクト指向の開発プロセス
- 設計だけではなくて開発プロセス自体も変えていくべき、ということが書かれていた。
- 自分のまわりだとこの辺はだいたいできている気がする。恵まれているのだろう。
Chapter10. オブジェクト指向の学び方と考え方
- オブジェクト指向のとっかかりのような話。
- プログラミング経験が浅い人の指導をやる際は参考にしたい。
雑談
最後に、ふわふわと考えたことを書きとめておく。
こういう設計の話は、しっかりがんばらなくても、肌感覚で8割くらいはうまくいく感じがある。(うまくいく、の定義はさておき。)
自分が世の中で認知可能な問題のうち、8割くらいが解けそうな問題として、その内8割の問題については、しっかりした設計なしでうまくいけば、 0.8(そもそも解けそうな問題) * 0.8(うまくいく割合) = 0.64 で6.4割くらいの勝率になる。
これと比べて、設計をしっかりやる場合は、どのくらい勝率があがるのだろうか。
仮に、うまくいく割合が9割になったとして、0.8 * 0.9 = 0.72 くらいだろうか。
そうすると、0.64 -> 0.72 にどのくらいコストをかける必要があるのだろうか、という疑問が湧く。
うまくいく8割に対するうまくいかない2割を克服しようとすると、その2割のコストが、全体のコストの8割になりそうな気がする。いわゆるパレートの法則だ。 一方、うまくいかない2割の中に、発生し得る致命的な問題の8割が含まれているかもしれない。
コストバランスは難しい。
