オススメされたので読んだ。
前半はデータとロジックを一緒に定義していこう(ドメインオブジェクトの定義)、
後半はシステム全体でどうやってドメインオブジェクトやその他の部分を作って行くのかという内容。
説明については前半はかなり具体的に、後半はアプリケーションよるのでやや抽象的な印象だった。
ぼ
...続きを読むんやり考えていたことを言葉に表してくれた感するし、
普段しない習慣だけど取り入れると良さそうな習慣もあった。
-------
以下、メモ・気になった点
- 値オブジェクトを作る
- コレクションもラップする
- 条件分岐は書かない
- elseは特に複文になるからだめ
- enum setを使って状態遷移図を作ろう
- やってみようとしたことあるけど上手くいかなかった。
- 今作ってるアプリが丁度複雑な状態遷移を持つので再度試してみたい
- データモデルに対するドメインモデルの考え方
- ドメインオブジェクトはデータと業務オブジェクトが一体何なっているクラス
- オブジェクト指向の本来の使い方
- ドメインオブジェクトを作って参照関係を整理した状態をドメインモデルと呼んでいる
- 業務のロジックがアプリケーション層からドメインモデルへ移る
- 業務フローで最初に発生するオブジェクトはその後で発生するオブジェクトを知らない。
- 全体を俯瞰する手段
- パッケージ図と業務フロー図
- 更新系のサービスでは使う前にデータが正しい状況にあるかどうかを事前にチェックする
- ドメインオブジェクトがテーブルのマッピングオブジェクトになるのは良くない。業務のロジックとデータの管理が関心の主なオブジェクトにデータベースの関心を持ってくるのは良くない。
- IDやグループを表すカテゴリはURIのパスパラメータに。
- クエリパラメータにすべきはオプショナルなパラメータ