「現場で役立つシステム設計の原則」を読んでます（1-3章）

DDDやっていきたいなーとか言ってたら同期にこの人の本良いっすよと言われて読んでみたのだが思った以上に良い感じだった

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

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

ソフトウェアの変更が大変なのはどこをどのように変えればいいのかが分かりにくいのが原因。
だから分かりやすい構成、設計にするべき。
始めの方は「変数の命名はxとかじゃなくて意味がわかるものにしようね」とか、
「DRY原則を守る」とかリーダブルコードに書いてあるような基礎的ですぐに実践しやすいことが記載されている。

ここで数値だったらなんでもbuildinの型使っちゃダメよと言っている。
例えばお金を示す値だったら整数だからとりあえずint型かなとしがちである。
が、システム内ではintの最大値と同じ金額を使うパターンが無いとか、100円単位で使われる可能性がある。
そのため専用の型として「値オブジェクト」を使い仕様を厳しくするべきである。
これにより異常値が入ってエラーが発生するということを防ぎやすくなる。

エリック・エヴァンスのDDD本とか実践DDD本とかだと割と後の章で値オブジェクトの概念が解説されるので1章目でこの話をするのかーと思った。
でも確かに「〇〇という概念がある。それは〜」という説明よりは「こういう課題があるので対策としてこういう設計がある。これを〇〇という。」という方がストーリーだっていて分かりやすかった。
また、よくエンティティと値オブジェクトの違いは可変か不変かですよという説明は見ていたのだが、なんでそういう分け方にしてるのかとかはよくわかっていなかった。
この書籍だと値オブジェクトの利用例があり分かりやすい。（他の書籍や記事でもあったのかもしれないがたどり着けてなかった）

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

基本はif-else文だと入れ子構造が深くなっていて複雑になるから控えようね、という話。
対策として「ガード節を使う」、「カテゴリ用のEnum作っておく」、「多態性（ポリモーフィズム）をもたせる」などがある。
これは書籍にはなかったが個人的には以下のような辞書型を使ったスクリプトで場合分けを行うことが多い。（上司に教えてもらった）

# 元コード
fruit = input()
if fruit == 'apple':
  return 100
else if fruit == 'orrange':
  return 200
else
  return 0

# 改良版
fruit = input()
prices = {'apple': 100, 'orrange': 200}
return prices.get(fruit, 0)

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

書籍ではデータクラスとロジックは分けないで書こうという話をしている。
正直言うと僕は役割が異なるから別で分けるものという認識だった。
しかしここを分けてしまうとデータクラス、ロジックの変更の影響範囲がどこなのかを調査するのが難しくなってしまうという問題がある。
データクラスとロジックをあわせて業務内容を再現したオブジェクトをドメインオブジェクトという。

また三層アーキテクチャについても触れている。ここでいう三層は以下の層を示す。

1. プレゼンテーション層
2. アプリケーション層
3. データソース層

n層とかレイヤーアーキテクチャとかはよく聞くのだが、上記の層含めどういう層があるのかとかはいまいち分かってなかった。
MVCでいうとそれぞれV, C, Mが対応してるんだろうか。
同じような役割の層でも呼称とか変わる場合もあるし難しいものである。flaskとかだとMVTだし
書籍では業務領域を表すドメインオブジェクトの集合であるドメインモデル（ここが一番複雑な処理になるはず）を別の1つのレイヤとして持つことで他の三層の記述は簡潔になる。

ふりかえり

手元に以下のDDD関連の古典がある。まだ全部は読みきれてない。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

頑張って古典を読んで理解しようと思ってたのだが、その途中で「現場で役立つシステム設計の原則」に触れておもしれーってなったので一通り読み進めたいところ。
これ読み終えたら上記2冊も読んでより理解を深めたい。
割と実装してる最中でも（この実装この階層であってんのか……？）となって開発に手間取ったり手戻りすることがあったりするので、サッと判断して爆速で開発できるようになりたいものである。
引き続き4章以降も読み進めます。