2020/06/052020/06/15

【書評】リーダブルコードの次に読む本として『現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法』

こんにちは、Nash です。

最近、先輩に DDD の文脈で下記の本をおすすめされたので読んでみました。

ということで、この記事は『現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法』のレビュー・書評の記事になります。

では、見ていきます。

現場で役立つシステム設計の原則～変更を楽で安全にするオブジェクト指向の実践技法

第1章　小さくまとめてわかりやすくする

第2章　場合分けのロジックを整理する

第3章　業務ロジックをわかりやすく整理する

第4章　ドメインモデルの考え方で設計する

第5章　アプリケーション機能を組み立てる

第6章　データベースの設計とドメインオブジェクト

第7章　画面とドメインオブジェクトの設計を連動させる

第8章　アプリケーション間の連携

第9章　オブジェクト指向の開発プロセス

第10章　オブジェクト指向設計の学び方と教え方

本の概要

いきなりですが、個人的にはタイトルが本の実態を表していないように感じます（まぁ、出版業界の事情とかがありそうなので仕方ないですが）。

この本の実態の内容は、「OOP ＋ DDD のエッセンスを実際のアプリケーションに落とし込むに至る説明」って感じの本です。

そのため、技術一辺倒ではなくて、実際にアプリケーションに落とし込むための考え方なども出てきます。また、OOP などの解説もあり広めに解説をしているので、DDD についてはコアな観点に絞られて解説がされている印象です。

良かった点

「なぜ」こういう設計・コードなのかが書かれてる

OOP についての実際のコードはもちろんだけど、「なんでこうするべきなんだっけ？」の理由に強くフォーカスされている説明なので、「そうそう、OOP ってこうあるべきだよね」という理解が進む。

OOP だけでなくて、DDD などでも全体的に「なぜ」のところに強くフォーカスされているので納得感をもって本を読める。

DDD の入門としてあり

DDD の中でも大事な観点などが実コードを交えて説明されるので、入門として良さそう。

注意点として、アプリケーションサービス・ドメインサービスとかの説明がなかったので、DDD のすべてを網羅した説明ではないと思う。

逆に DDD におけるコア・重要なポイントに絞られている説明なので、DDD の触りを手軽に知りたい人には良さそう。

ただ、個人的には単純に DDD を知りたいなら、今まで読んだ中ではボトムアップドメイン駆動設計の記事で学ぶのがおすすめですが。（これ、気付いたら書籍化されてるじゃん！今度、買って読もう。）

技術だけの話でない

全体的に技術寄りのトピックではある。ただ、「ドメインをどうやってシステムに落とし込むか？」という、ソフトスキル的な範囲も書かれていて、実際に開発する場面でも大事な観点が盛り込まれている。

気になった点

説明が冗長でわかりにくい

説明がやや婉曲でわかりにくいように感じる点もいくつかあった。というのも、上から読んでもスラスラ頭に入ってこないところが多いので。

すべてを細かく正確な日本語で説明しすぎてるのかなー、という印象。

頭にスラスラ入らないところは、何度か読めば理解はできるけど、ストレスはある。

理想論すぎて現場で役に立つかが怪しい

使われるアーキテクチャが尖りすぎているので、現場でこの設計で GO サインが出ないんじゃないかな、と思う。

というのも、

DDD
イベントソーシング
CQRS

などを使うことを推奨していて解説がされているが、自分の知っている限りのシステム開発ではこれらの設計ってややアブノーマルな印象。

もちろん、べき論というか理想論では、それぞれ採用すべきだとも思っているけれども

開発難易度が高かったり
有識者が少ない
学習コストが高い
ナレッジが少ない

などなどの理由でこれらを採用するのは一般的なチームでは少し難しそうだと思う。

そういう意味合いで、この本のナレッジが「現場で役に立つ」か？というと正直疑問です。

学んだこと・思ったこと

個人的にこの本で学んだポイントとか、思ったポイントのまとめです。

OOP(or DDD）において「状態に依存する処理をする場合、使う側が状態を事前に確認する」が基本事項になる、とのこと。これは知らなかった。
３層アーキテクチャと DDD の併用では、アプリケーションレイヤーがドメインレイヤーとつながって処理を依頼する。
ドメインレイヤーでの処理が複数になりシナリオ化したら、シナリオレイヤーみたいのを作って一連の処理をまとめるのも良い。「アプリケーションレイヤー ⇒ シナリオレイヤー ⇒ ドメインレイヤー」の流れになる。なので、シナリオレイヤーは複数のドメインをまとめる。
decorator も全部ドメインオブジェクトに入れる。「データが見つかりませんでした」「x 件が見つかりました」などの判断ロジックだけでなくて、そのテキスト自体もドメインモデルで管理するべき。ビューとモデルの分離の原則に違反しているが、それよりも関心を１つにまとめるほうがよいから、とのこと。まじか。
「(p183)イベントソーシングですべてのデータを管理しろ」は、少しオーバーな気もするけど。。。必要な場面があるのは理解できるけど、今までも何個も Web サービスに携わってきたけどそこまでやってるところないよな。。。
「(p184)テーブルにカラムを新しく追加するとき、既存のテーブルを使わないで新しく専用のテーブルを作る」は、やりすぎ、というかテーブル設計が余計に汚くならないのかな？著者の主張としては、「NOT NULL 制約が解禁されるくらいなら、新しくテーブル作れ」なのだけど、さすがにやりすぎでは？とも思ってします。。。