purucat’s blog

寿司よ止まれっ!

"「実践ドメイン駆動設計」から学ぶDDDの実装入門" 5章感想 (全14章)

"「実践ドメイン駆動設計」から学ぶDDDの実装入門"

「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)

「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)

のレビューをこまめに記載していく


5章 「エンティティ」〜 一意な識別子で同一性を識別

良い所

  • みんな何となくやっている実装を言語化してsummarizeするのに役立つかも? (例:ユースケースのシナリオでの「変更」というワードを使用する主語がエンティティ候補になる)
  • Software Designの歴史を知れる

悪い所

  • 代理識別子(システム上のキー)はGoogleのexact matchで調べる限りでは一般的ではなさそう。hibernateのドキュメントを眺めた感じだとidentifier propertiesがソースかな?まだ識別子プロパティの方が良いかも。

気になった所

  • Nothing

学んだ事

  • モデルの発展に合わせてユビキタス言語を用語集に反映。
  • DDD (Domain Driven Development) はオブジェクトモデリングを中心にシステム構築を考える。

    • DOA (Data Oriented Approach / Data Driven Approach) はデータ間の関係性(DB設計)を中心にシステム構築を考える。オブジェクトの振る舞いが欠乏してドメインモデル貧血症になりがち。だが、データ構造とプログラムは切り離されている。又、一度モデリングしたデータ構造は長期にわたって変化しにくい。
      • POA (Process Oriented Approach) は業務プロセスの流れを元にシステム構築を考える。データがプログラムに依存してしまう。(1960代 ~ 1970代の主流)
  • 自己カプセル化」::= コンストラクタで、引数のvalidation 機能を持つsetterを介して値を設定する。

Entity

EntityのPropertyのバリデーション

  • Design By Contract(契約による設計) / Programming By Contract(契約プログラミング) ::= (Bertrand Meyer氏によるオブジェクト指向入門という書籍で紹介されている考え方。原著は1990年頃発売?)
    • https://developer.hatenastaff.com/entry/2016/09/01/163542 にあるのがわかりやすい。

      関数の仕様を決める時に、関数を実行するのに何が必要か(事前条件)、そしてどういった結果を返してくれるのか(事後条件) をはっきりさせて分析することで、関数の責任や他の部分との 境界を明確にして整理することができます。さらに、契約に基づいて関数の事前条件や事後条件をコード上に表明(assertion)として表現することで、コードのまちがいに気付きやすくなり、信頼性の高いソフトウェア開発につながります。

Entityオブジェクト全体のバリデーション

  • 対応するバリデータをクラスで適切なタイミングで行う。 対応するバリデータクラスに対象Entityとinvalid時のhandlerをコンストラクタで渡してvalidateするやり方は考えたことがなかった!

複数個のEntityオブジェクト組み合わせ時のバリデーション

  • Domain serviceで制御するらしい。具体例が思いつかないが7章の解説を待とう。

分からないこと

  • Nothing