感情タグBEST3
Posted by ブクログ
実務の中でドメイン駆動の設計開発をどのようにしていったらいいか、具体的な手順と留意点が書かれていました。ドメイン駆動開発の入門書としてとてもいい本だと思いました。
Posted by ブクログ
オブジェクト志向で開発、設計する意義や具体的な開発方法が紹介されていて、とにかく分かりやすかった
オブジェクト志向の説明は抽象的でとっつきにくいものも多い印象だが、本書はタイトル通り現場に沿ったものであることをとても感じた
少しずつ日々の開発に取り込んでいきたい
Posted by ブクログ
オブジェクト指向だけでなく、ドメイン駆動設計やマイクロサービスアーキテクチャの足掛かりになる良本。
よくあるオブジェクト指向の本を読んでピンと来なかった方や、業務システムの設計や実装で苦しんだ経験のかる方にはきっと内容が刺さります。
Posted by ブクログ
オススメされたので読んだ。
前半はデータとロジックを一緒に定義していこう(ドメインオブジェクトの定義)、
後半はシステム全体でどうやってドメインオブジェクトやその他の部分を作って行くのかという内容。
説明については前半はかなり具体的に、後半はアプリケーションよるのでやや抽象的な印象だった。
ぼんやり考えていたことを言葉に表してくれた感するし、
普段しない習慣だけど取り入れると良さそうな習慣もあった。
-------
以下、メモ・気になった点
- 値オブジェクトを作る
- コレクションもラップする
- 条件分岐は書かない
- elseは特に複文になるからだめ
- enum setを使って状態遷移図を作ろう
- やってみようとしたことあるけど上手くいかなかった。
- 今作ってるアプリが丁度複雑な状態遷移を持つので再度試してみたい
- データモデルに対するドメインモデルの考え方
- ドメインオブジェクトはデータと業務オブジェクトが一体何なっているクラス
- オブジェクト指向の本来の使い方
- ドメインオブジェクトを作って参照関係を整理した状態をドメインモデルと呼んでいる
- 業務のロジックがアプリケーション層からドメインモデルへ移る
- 業務フローで最初に発生するオブジェクトはその後で発生するオブジェクトを知らない。
- 全体を俯瞰する手段
- パッケージ図と業務フロー図
- 更新系のサービスでは使う前にデータが正しい状況にあるかどうかを事前にチェックする
- ドメインオブジェクトがテーブルのマッピングオブジェクトになるのは良くない。業務のロジックとデータの管理が関心の主なオブジェクトにデータベースの関心を持ってくるのは良くない。
- IDやグループを表すカテゴリはURIのパスパラメータに。
- クエリパラメータにすべきはオプショナルなパラメータ
Posted by ブクログ
実践的なオブジェクト指向プログラミングを学べる。
オブジェクト指向とはプログラムの整理整頓の技術である。
バグを埋め込みにくく、ソース変更した際の影響範囲を小さくする。
オブジェクト指向でのプログラミングは、手続き型と比較して時間がかかる。
中身が読みにくくぐちゃくちゃのプログラムも、
オブジェクト指向に従って一定の規律で整理されたプログラムも
使い手にとっては、「動く」ということに変わりない。
だけど、長期的に運用を継続していくにつれ、後者のメリットが大きくなっていく。
時間をかけてでも、オブジェクト指向でのプログラミングをしていきたい。
発注側に理解されない(見えない)部分なので、ツライですところがありますが。
Posted by ブクログ
オブジェクト指向プログラミングとドメイン駆動設計の考えを実践的なシステム設計に落とし込むやり方が書いてありました。
もともとオブジェクト指向プログラミングやドメイン駆動設計を勉強していたが、より具体的なイメージがついたなと思います。
ちょっと真似できないなと思う内容もありましたが、非常に参考になる内容も多かったです。
ただ、これからシステム設計を始める人が初めて読む本ではないなと思いました。
(外部設計を担当することになったから勉強したい、みたいな)
オブジェクト指向やドメイン駆動設計を軽くでも知っている人が、より実践的な知識、手法を知るための本だと思います。
Posted by ブクログ
初心者向けかと思いきや、かなり高度な内容も含まれている
しかも、それがかなりわかりやすく、簡潔に書かれている
タイトルに「原則」とあるが、まさにその通りだと思う
Posted by ブクログ
オブジェクト指向を勉強する中で、どのような設計が運用しやすいのか考えていた中で出会った本書。
ドメインを意識して設計をすることで、変更箇所、影響範囲を把握しやすいシステムを作ることができそうだ。
実際にDDDを使って実装していくのは時間がかかりそうだが、本書で紹介されていた値オブジェクトやドメインモデルの考え方を使って少しずつなれていければと思う。
あと、デザインの4原則がDDDに活かせるという話は驚きがあった。
Posted by ブクログ
オブジェクト指向設計を解説した一冊。コンポーネント単位の概要設計というよりはコードレベルのソフトウェア設計の話が中心。恥ずかしながら値オブジェクトや専用クラスの考え方を知らなかったので第1章から非常に勉強になった。第8章の「それはWeb APIではなくWebサービス」という視点は目から鱗…
Posted by ブクログ
int a; にはじまり、DDDに終わるすごい本。「きれいなコードを書くための勉強」と、「業務アプリケーションの設計/開発ができるようになるための勉強」との間にある断絶を埋めてくれる一冊。コード一行から積み上げていくので、時折どこに行くのか不安になるかもしれないが、素直な心で読み、熟考しながら適用するのがよいと思う。
Posted by ブクログ
【よかったところ】
1. システムの動的な側面(振る舞い)をドメインモデルを基本としたオブジェクト指向で整理し、静的な側面(データ構造)を追記型のモノ・コト指向で整理するという、増田さんの考えが詳しく説明されているなぁと思った
2. 明示的に書いていないけど、オブジェクト指向というよりインターフェイス指向で交換可能な部品を組み合わせるボトムアップ的な考え方が重要になると思った。
3. 一方データベース設計(モノ・コト指向の設計)はトップダウンに進めないとなぁと。
【そうでもなかったところ】
1. 「部分と全体」というフレーズが出るけど、オブジェクト指向設計においては部分ではなく部品として解釈しないと理解できないものだった(しばらく混乱した)
2. 業務システムでは巨大な画面はありがちなので、それを分割してタスクベースの画面構成にする前提になっているのは現実的ではなさそう(B2Cだったり提案するときにはよさそう)
なので、巨大な画面の構成を部品として統制する考え方は自分たちで考えなければいけないなぁと。
3. ビューモデルの考え方がないので、「ドメインモデルがCSSクラス名を知っている」という世界観になってしまい、とても残念な感じ。
Posted by ブクログ
ドメイン駆動、オブジェクト指向によるソフトウェア設計の原則が分かりやすく解説されている。想定言語はJava。
設計、コードに落とす内容はとても具体的で、参考になる。
しかし、原則なので基本的に従うべきだと思える記述が多いが、実務上は本書の方針では対応出来ない場合も出てきそう。
例えば、2章の料金計算の例で、区分(シニア、大人、子供)毎に料金計算クラスを分ける例が載っているが、子供3人目以上は半額、などのルールに対応するのが難しくなる。このような結びつきの強い型をインターフェースと継承でグルーピングするのは変更コストが高いので、関数型言語の多くが持つ代数的データ型によるグルーピングにした方が良いと思う。
また、「〜するのがオブジェクト指向らしい」「〜するのがオブジェクト指向の基本」のような記述はたくさんあるが、
著者が考えるオブジェクト指向の定義は載っていないようでモヤモヤする。読者は何に基づいて「オブジェクト指向らしさ」を判断すればよいのだろう?
Posted by ブクログ
DDDを含むシステム設計の基本的な考え方について平易な言葉で書かれており役に立つが、もう少し整理すれば短くなり、もっとわかりやすくなりそうにも感じた。