現場で役立つシステム設計の原則 の商品レビュー

増田亨(著者)

2024/09/17

実践的なオブジェクト指向プログラミングを学べる。
オブジェクト指向とはプログラムの整理整頓の技術である。
バグを埋め込みにくく、ソース変更した際の影響範囲を小さくする。
オブジェクト指向でのプログラミングは、手続き型と比較して時間がかかる。
中身が読みにくくぐちゃくちゃのプログラムも、
オブジェクト指向に従って一定の規律で整理されたプログラムも
使い手にとっては、「動く」ということに変わりない。
だけど、長期的に運用を継続していくにつれ、後者のメリットが大きくなっていく。
時間をかけてでも、オブジェクト指向でのプログラミングをしていきたい。
発注側に理解されない（見えない）部分なので、ツライですところがありますが。

2024/03/05

実務の中でドメイン駆動の設計開発をどのようにしていったらいいか、具体的な手順と留意点が書かれていました。ドメイン駆動開発の入門書としてとてもいい本だと思いました。

2024/02/24

オブジェクト志向で開発、設計する意義や具体的な開発方法が紹介されていて、とにかく分かりやすかった

オブジェクト志向の説明は抽象的でとっつきにくいものも多い印象だが、本書はタイトル通り現場に沿ったものであることをとても感じた

少しずつ日々の開発に取り込んでいきたい

2023/07/30

オブジェクト指向プログラミングとドメイン駆動設計の考えを実践的なシステム設計に落とし込むやり方が書いてありました。
もともとオブジェクト指向プログラミングやドメイン駆動設計を勉強していたが、より具体的なイメージがついたなと思います。

ちょっと真似できないなと思う内容もありましたが、非常に参考になる内容も多かったです。

ただ、これからシステム設計を始める人が初めて読む本ではないなと思いました。
(外部設計を担当することになったから勉強したい、みたいな)
オブジェクト指向やドメイン駆動設計を軽くでも知っている人が、より実践的な知識、手法を知るための本だと思います。

2023/07/14

初心者向けかと思いきや、かなり高度な内容も含まれている
しかも、それがかなりわかりやすく、簡潔に書かれている
タイトルに「原則」とあるが、まさにその通りだと思う

2022/06/19

オブジェクト指向だけでなく、ドメイン駆動設計やマイクロサービスアーキテクチャの足掛かりになる良本。
よくあるオブジェクト指向の本を読んでピンと来なかった方や、業務システムの設計や実装で苦しんだ経験のかる方にはきっと内容が刺さります。

2022/04/10

オブジェクト指向を勉強する中で、どのような設計が運用しやすいのか考えていた中で出会った本書。
ドメインを意識して設計をすることで、変更箇所、影響範囲を把握しやすいシステムを作ることができそうだ。
実際にDDDを使って実装していくのは時間がかかりそうだが、本書で紹介されていた値オブジェクトやドメインモデルの考え方を使って少しずつなれていければと思う。
あと、デザインの4原則がDDDに活かせるという話は驚きがあった。

2020/01/31

# 書評☆3: 現場で役立つシステム設計の原則 | 失敗の原因はデータクラス/機能クラスによる手続き型設計

## 概要
- 書名: 現場で役立つシステム設計の原則
- 副題: 変更を楽で安全にするオブジェクト指向の実践技法
- 著者: 増田 亨
- 出版日: 2017-07-18
- 読了日: 2020-01-31 Fri
- 評価: ☆3
- URL: https://book.senooken.jp/post/2020/02/04/

## 評価
書名どおり，現場で役立つシステム設計の方法について書いてあった。いろんなところで参照されており，評判が高かったので興味を持って読んだ。

内容としては，プログラミング言語Javaを例としたオブジェクト指向設計について論じたものであり，リファクタリングやドメイン駆動設計やDB，Web APIとの連携の設計についても書いてあった。

一番印象に残っているのが，「Chapter 3 業務ロジックをわかりやすく整理する」だ。変更しにくく，似たような処理が至るところに記述される状態ができる原因として，データクラスと機能クラスを使った手続き型設計を指摘していた。これはたしかにそのとおりだと思った。

内容全体として，オブジェクト指向に沿った設計を行い，業務の関心事項の単位でクラスを作ることでうまく設計できるという話だった。

いろいろ書いてあったが，結局はオブジェクト指向を意識してやれば大丈夫という内容だった。

## 結論
既存コードの失敗例を上げながら，なぜダメなのかどうすればいいのかをオブジェクト指向に従った形で解説されていた。

オブジェクト指向を理解して実践できていれば，当然と思うような内容がやや多かった。リファクタリングなどの話も交えていて，まあまあよかった。

ただ，巷での前評判が高かったので，それと比べるとやや過大評価に感じた。

あくまで著者が考える方法のひとつであり完璧とも思わない。それに，知っていても実際に自分の場面で適用できるかどうかはある程度経験が必要になる。

そういう意味で，普段の開発に問題を抱えている人が読むと参考になるだろうと感じた。

2019/05/27

DDDを含むシステム設計の基本的な考え方について平易な言葉で書かれており役に立つが、もう少し整理すれば短くなり、もっとわかりやすくなりそうにも感じた。

2019/04/01

オススメされたので読んだ。

前半はデータとロジックを一緒に定義していこう（ドメインオブジェクトの定義）、
後半はシステム全体でどうやってドメインオブジェクトやその他の部分を作って行くのかという内容。

説明については前半はかなり具体的に、後半はアプリケーションよるのでやや抽象的な印象だった。

ぼんやり考えていたことを言葉に表してくれた感するし、
普段しない習慣だけど取り入れると良さそうな習慣もあった。

-------
以下、メモ・気になった点

- 値オブジェクトを作る
- コレクションもラップする
- 条件分岐は書かない
- elseは特に複文になるからだめ

- enum setを使って状態遷移図を作ろう
- やってみようとしたことあるけど上手くいかなかった。
- 今作ってるアプリが丁度複雑な状態遷移を持つので再度試してみたい

- データモデルに対するドメインモデルの考え方
- ドメインオブジェクトはデータと業務オブジェクトが一体何なっているクラス
- オブジェクト指向の本来の使い方
- ドメインオブジェクトを作って参照関係を整理した状態をドメインモデルと呼んでいる
- 業務のロジックがアプリケーション層からドメインモデルへ移る

- 業務フローで最初に発生するオブジェクトはその後で発生するオブジェクトを知らない。

- 全体を俯瞰する手段
- パッケージ図と業務フロー図

- 更新系のサービスでは使う前にデータが正しい状況にあるかどうかを事前にチェックする

- ドメインオブジェクトがテーブルのマッピングオブジェクトになるのは良くない。業務のロジックとデータの管理が関心の主なオブジェクトにデータベースの関心を持ってくるのは良くない。

- IDやグループを表すカテゴリはURIのパスパラメータに。
- クエリパラメータにすべきはオプショナルなパラメータ