"「実践ドメイン駆動設計」から学ぶDDDの実装入門" 5章感想 (全14章)
"「実践ドメイン駆動設計」から学ぶDDDの実装入門"
「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)
- 作者: 青木淳夫,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2019/05/31
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
5章 「エンティティ」〜 一意な識別子で同一性を識別
良い所
- みんな何となくやっている実装を言語化してsummarizeするのに役立つかも? (例:ユースケースのシナリオでの「変更」というワードを使用する主語がエンティティ候補になる)
- Software Designの歴史を知れる
悪い所
代理識別子
(システム上のキー)はGoogleのexact matchで調べる限りでは一般的ではなさそう。hibernateのドキュメントを眺めた感じだとidentifier properties
がソースかな?まだ識別子プロパティ
の方が良いかも。
気になった所
- Nothing
学んだ事
- モデルの発展に合わせてユビキタス言語を用語集に反映。
DDD (Domain Driven Development) はオブジェクトモデリングを中心にシステム構築を考える。
自己カプセル化
」::= コンストラクタで、引数のvalidation 機能を持つsetterを介して値を設定する。
Entity
EntityのPropertyのバリデーション
Design By Contract(契約による設計)
/Programming By Contract(契約プログラミング)
::= (Bertrand Meyer氏によるオブジェクト指向入門という書籍で紹介されている考え方。原著は1990年頃発売?)- https://developer.hatenastaff.com/entry/2016/09/01/163542 にあるのがわかりやすい。
関数の仕様を決める時に、関数を実行するのに何が必要か(事前条件)、そしてどういった結果を返してくれるのか(事後条件) をはっきりさせて分析することで、関数の責任や他の部分との
境界を明確にして整理することができます。
さらに、契約に基づいて関数の事前条件や事後条件をコード上に表明(assertion)として表現することで、コードのまちがいに気付きやすくなり、信頼性の高いソフトウェア開発につながります。
- https://developer.hatenastaff.com/entry/2016/09/01/163542 にあるのがわかりやすい。
Entityオブジェクト全体のバリデーション
- 対応するバリデータをクラスで適切なタイミングで行う。 対応するバリデータクラスに対象Entityとinvalid時のhandlerをコンストラクタで渡してvalidateするやり方は考えたことがなかった!
複数個のEntityオブジェクト組み合わせ時のバリデーション
- Domain serviceで制御するらしい。具体例が思いつかないが7章の解説を待とう。
分からないこと
- Nothing