Recommended
More Related Content
What's hot
What's hot (10)
Similar to 社内 DDD 勉強会 #2
Similar to 社内 DDD 勉強会 #2 (20)
More from shingo suzuki
社内 DDD 勉強会 #2
- 2. 注意事項 • 発表資料は後で SlideShare にあげます
- 3. 今回の範囲 • 第1部 ドメインモデルを機能させる • 第2部 モデル駆動設計の構成要素 • モデルを分離するアーキテクチャ • 構成要素のパターン • ライフサイクルのパターン • 第3部 より深い洞察へ向かうリファクタリング • 第4部 戦略的設計
- 4. アーキテクチャ • DDDを採用するうえでどのようなアーキテクチャを採用する か？ • ドメインモデルを置くレイヤをそれ以外から分離したい • ドメインモデルのレイヤが依存するものを少なくしたい
- 6. 依存性逆転の法則(DIP) • 上位のモジュールは下位のモジュールに依存してはならない • どちらのモジュールも「抽象」に依存すべきである クラス A クラス B 具象クラス A クラス B 抽象クラス B’
- 8. その他のアーキテクチャ • DDDをクリーンアーキテクチャやヘキサ ゴナルアーキテクチャと組み合わせて使っ てもよい • 右図の引用元 • https://8thlight.com/blog/uncle- bob/2012/08/13/the-clean-architecture.html • http://alistair.cockburn.us/Hexagonal+archit ecture
- 10. 構成要素に関するパターン ドメイン上の概念をどのようにオブジェクトに反映するか • 関係 • エンティティ • 値オブジェクト • サービス • ドメインイベント • モジュール
- 11. 関係 • モデル上での関係 • 現実に存在する２者の“関係”を抽 象化したもの • 実装上は • オブジェクトポインタ • カプセル化したもの • etc で一意ではない • 扱いやすくするには？
- 15. エンティティと値オブジェクト • エンティティ • オブジェクトの同一性が重要なもの • → 属性が一致しても同一とはみなせないもの • → 属性、クラスまでも異なっても同一とみなせるもの • 値オブジェクト • オブジェクトの属性のみが重要なもの • → オブジェクトの同一性は大事ではない
- 16. エンティティ • エンティティとしたオブジェクトは • ライフサイクルの連続性と同一性に集中すること • 本質的でない属性はそぎ落とす • 逆に同一性と関連した属性はそのエンティティと一緒になるようにする • 各オブジェクトに対して結果が一意となることが保証される操作を定 義すること • ID の取得などで実現できる • モデルとして • 同じものであるということが何を意味するかを定義しなければならない
- 17. エンティティ:余計な属性をそぎ落とす • 余計な属性＝エンティティのふるまい が必要としないもの • ユースケースとして • 電話番号、住所での顧客を検索すること がある 顧客ID 名前 平均販売量 製品カテゴリ 顧客 セールスマン 優先順位 連絡先電話番号 連絡先住所 販売連絡先
- 19. 値オブジェクト • あるモデル要素が、その属性しか関心の対象にならないのであ れば、その要素を値オブジェクトとして分類する • 値オブジェクトは • 不変なものとして扱うこと • 同一性を与えず、複雑な設計を避ける • 設計としてはできるだけ値オブジェクトに切り出せた方がよい
- 21. サービス • オブジェクトとしてモデル化すると不自然なもの • エンティティでも値オブジェクトなどの名詞的なものではない • ドメイン上に存在する操作など動詞的なもの • サービスは各レイヤに配置可能 • アプリケーションレイヤのアプリケーションサービス • ドメインレイヤならドメインサービス • 例：銀行口座ドメインにおける資金振替サービス • 2つの口座とグローバルなルールを伴うので、口座のメソッドにすると 扱いづらくなる
- 22. ドメインイベント • ドメイン内での何かの出来事を抽象化する • 「○○するときに」 • 「もしそうなったら、…」 • 「…の場合は、通知してほしい」 • など • ユビキタス言語としても「○○イベント」と組み込むとよい • 条件がそろったときに、オブジェクトがこの「イベント」を発 行して、通知される側はこの「イベント」を受け取って何かす るようにしておくと便利
- 23. モジュール • モジュール自体もコミュニケーションの仕組み • 「では『顧客』モジュールについて話しましょう」 • モジュールは • 疎結合・高凝集を目指してつくる • 特に、ドメイン層を他から分離する • モジュールにもユビキタス言語の一部になる名前を付けること • 単一の概念オブジェクトを実装するコードはすべて、同一のオブジェ クトにならなくても、同一のモジュールにまとめること
- 24. 構成要素のまとめ ドメインモデルの構成要素は次がある • 関係 • エンティティ • 値オブジェクト • サービス • ドメインイベント • モジュール
- 27. ライフサイクルに関するパターン • 集約 • オブジェクトの所有権・境界を明確にする • ファクトリ • 集約の生成・再構成を行い集約内部構造のカプセル化を維持する • リポジトリ • 永続化されたオブジェクトへのアクセス手段を提供する
- 30. 集約ルート • 集約ルートの責務 • グローバルな同一性を持つ • 不変条件をチェックする最終的な責務を負う • 削除は、境界内部のすべてを一度に削除する • 集約内のエンティティ • 集約ルート内での同一性をもつ
- 31. ファクトリ • 集約生成の責務を持つ • オブジェクト、というより集約全体が対象 • クライアントが生のコンストラクタは呼び出さないようにする • 実装の際には次に注意 • 各操作をアトミックに行うようにする • 入力パラメータを慎重に選択する クライアント ファクトリ 生成物 生成物 new(parameter) 生成
- 32. リポジトリ • 責務 • 永続化した集約を再構成する • クライアントにグローバルな集約ルートへのアクセスを提供する • 実装の際は • 型を抽象化する • クライアントから切り離す利点を生かすこと • トランザクション制御をクライアントにゆだねること クライアント リポジトリ 一致するオブジェクト 選択条件 委譲 ファクトリ DBインターフェース etc
- 33. ライフサイクルのまとめ • 集約を使い、オブジェクトの境界・所有権を明確にする • 生成の責務をオブジェクトからファクトリに移動する • 生成したあとのオブジェクトはリポジトリから取得できるよう にする
- 35. その他 • 何か聞いてみたい話があれば企画します • 最近の仕事の話 • 関数型言語 (Scala, Haskell, etc) • Android, Kotlin • コンパイラ • パフォーマンス関連 • 機械学習 • 計算量理論・組み合わせ数学 • 量子コンピューティング • ボードゲーム
- 36. 以下補足
- 37. ドメインモデル貧血症 • オブジェクトが単なる属性の入れ物になっている状態 • ある機能を実装するときに、getter で必要な情報を取り出して 呼び出し元側でデータを操作して setter でオブジェクトの更新 をしてたりしてないか？
- 38. 参考文献 • エリック・エヴァンスのドメイン駆動設計 • 実践ドメイン駆動設計 • ドメインイベントについてはこちらで言及されている
Editor's Notes
- ドメイン駆動設計の原理についての話 実装etcの話はまだ少ない