Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Implementing Domain-Driven Design: Part 1

3,290 views

Published on

2013 年に出版された "Implementing Domain-Driven Design" の内容を解説します。第 1 回の今回は、大上段の「なぜ?」「いつ?」から初めて、DDD のイメージをつかむためのサンプルコードを見ていきます。

Published in: Technology

Implementing Domain-Driven Design: Part 1

  1. 1. Implementing Domain-Driven Design Part 1: Getting Started with DDD 神原 淳史 @atsukanrock 2015/08/07 今だから学びたい!DDD (Sansan .NET勉強会 #10)
  2. 2. 自己紹介 • 神原 淳史 @atsukanrock https://github.com/atsukanrock • Sansan株式会社 (2014年11月から) アバナード株式会社 (2011年7月~2014年10月) • Software Developer Domain-Driven Design / .NET / C# / Azure Cloud (´・ω・`)
  3. 3. 今日のお題は… Today’s Contents
  4. 4. DDD: Domain-Driven Design
  5. 5. IDDD: Implementing DDD
  6. 6. From DDD to IDDD DDD published in 2004 IDDD published in 2013 コンセプトを提示 具体的な設計、Do / Don’tを提示 ベーシックでやや古いアーキテクチャ DDD発刊以降に出てきたアーキテクチャも導入 こいつの紹介
  7. 7. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  8. 8. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  9. 9. なぜDDDを採用するのか Why do we employ DDD?
  10. 10. DDDならできます できること 効果 Domain Expertsが持つ業務知識をモデル化 • 個々のDomain Expertに分散していた ノウハウの共有 • 担当者が変わってもすぐに使える 開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応 Domain Expertsですら気付かなかった 新たな知見の発見 ∵ (なぜならば) モデル化することで: • 「すぐに」「何度でも」シミュレーション可能 • 抽象化により本質が見える • 単なる業務自動化でなくシステムが 事業を引っ張る
  11. 11. 前提 • Domain Expertsはチームの一員となる • Agile / Scrum • Domain Expertsとチームは共通の言語 (Ubiquitous Language) 、共通のモデルを使って会話する • 「お客には設計の話なんてするな」ではない
  12. 12. とかゆってるけど • Domain Expert is どこ • チームの一員になってくれてモデルの話ができるひとって… • DDDはCore Domain (事業差別化領域) に適用してこそ 最大の効果 • 「どの領域をシステム化するか」の選択権って…
  13. 13. DDDの本質の実践は困難…
  14. 14. それでも自社サービスなら… • サービスの根幹部分がCore Domainになる • Domain Expertsには自分たちがなる • 外部アドバイザーとかは居るかもしれない
  15. 15. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  16. 16. いつDDDを採用するのか When to employ DDD
  17. 17. 向き不向きがあります 複雑単純 長寿 短命 DDD 逃げる勇気 Access VBA とか? Transaction Script / Table Module
  18. 18. The DDD Scorecard from IDDD • 一言で言うと: DDDは複雑で長寿なシステムの 場合に使うべきもの • CRUD中心のシステムなら Scaffoldingとかで作れば良い • あと、ゲームとか証券とか にはたぶん向かない
  19. 19. 向き不向きがあります 複雑単純 長寿 短命 DDD 逃げる勇気 Access VBA とか? Transaction Script / Table Module 実際のシステム
  20. 20. 私見ですが • システム全体がDDDの使用が適切な特性を持っている わけではない (おそらくほぼ全てのシステムに言える) マスタ管理とか、単純なのがあるはず • DDDを採用するのは一部のCore Domainに絞って、 残りはScaffoldingとかTransaction Scriptで作れば良い 混ぜる勇気
  21. 21. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  22. 22. IDDDの全体像 The whole picture of IDDD
  23. 23. ざっくり言うと • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション
  24. 24. 今回は時間の都合上 • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション ここと (説明済み) ここ (の一部) だけ
  25. 25. IDDDは盛り沢山なので… 残りは次回以降に!! …だけどちょっとだけ
  26. 26. Domainの分割、Bounded Context • システム化対象領域を いかに分割するか • (今流行りの) Microservice にも通じる考え方
  27. 27. Architecture ※私の大好物 • Layers • Dependency Inversion Principle • Hexagonal / Ports and Adapters • Service-Oriented / REST • CQRS: Command-Query Responsibility Segregation • Event Sourcing and more…
  28. 28. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  29. 29. DDDのモデリング手法 DDD style modeling technique
  30. 30. オブジェクトおよび概念 • Entity • Value Object • Service • Domain Event • Module • Aggregate • Factory • Repository New in IDDD
  31. 31. 正しく知り、使うことで • Domainの知識がモデルに集約される • UI側に散ったりしない • 不純物が混じらない • トランザクション • セキュリティ • アプリケーション要件 • SOLID Principlesを守れる • オブジェクト指向の超大事な原則5つ
  32. 32. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  33. 33. Entity The core of domain modeling
  34. 34. A Poor Entity getter / setterのみのプロパティが並ぶ (単なるデータの入れ物) • SprintIdとStatusを合わせて設定すると いう知識がクライアントに • 実際にはValidationとかDB保存とか もっとやることが多い
  35. 35. A DDD Style Entity getter / setterのみのプロパティは 消えた 適切なValidation Domainの知識
  36. 36. Entity in IDDD • Identity大事 • 何をIdentityとするか • Identityが満たすべき要件 • Entityの生成 • コンストラクター • Factory
  37. 37. Entity in IDDD • Validation • Value Objectで守る • プロパティのSetterで守る • Validatorを切り出す • DBに行くようなValidationはしない (例: ユニークチェック) • Change Tracking
  38. 38. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  39. 39. Value Object To enrich your entities
  40. 40. もしValue Objectがなかったら EntityにDomainの知識を持たせる。 間違ってはいないが… プロパティがわらわらあって何かぼやけてる感じ ∵ ひとまとまりのコンセプトが他のコンテキストに 混じってしまっている
  41. 41. A sample Value Object Domainの知識
  42. 42. Value Objectのある世界 ひとまとまりのコンセプトが Value Objectにまとまった
  43. 43. Value Object in IDDD • Identityを持つモノでなく、等価交換可能 • Immutable • Value Equality (implements IEquatable<T>) • Side-Effect-Free Behavior • Persisting Value Objects • DB等への保存
  44. 44. Value Object in IDDD • Entity’s Identity as Value Object • 単なるString等でなくXxxIdクラスを作る • (↑とはいえ) 何でもかんでもValue Objectにはしない • 複数の属性もしくは振る舞いを持つものだけ • それ以外はプリミティブ型で済ます
  45. 45. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  46. 46. 少し複雑な例 (Application Service) A little bit complex example of Application Service
  47. 47. A sample Application Service DI前提 (changed from DDD) Query Service ※後述 Application Service • Domain Modelを使ってアプリケーション のトランザクションを実行 • 必要なセキュリティを実装
  48. 48. Domain Model in Application Service Entity Repository Value Object Service
  49. 49. Query Service? SQLベタ書き Application Layer of Hexagonal Architecture ※後述 • CQRS (次回以降のお話) のQuery Command (参照のみ) • データアクセスがRepositoryだけだとアプリケーション向け のQueryがしんどい (Join とかあって) EntityでなくData Transfer Objectを返す
  50. 50. Hexagonal Architecture? • 一言で言うと: Domain Modelさえ クリーンに保てば、 後は作りやすいように 作ればおk • DI (IoC) が前提になる • 詳しくは次回以降に…
  51. 51. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)
  52. 52. まとめ Wrap up
  53. 53. まとめ • DDD採用の目的: システムの価値を上げる • そのために、Domainモデリングの手法を学ぶ • IDDDが具体的な指針を示した
  54. 54. 捕捉 • 図、サンプルコードは全てIDDDから拝借した https://github.com/VaughnVernon/IDDD_Samples_NET • 実はDomain Modelをクリーンに保つには、それ以外の ところ (例えばDBアクセス周り) に相当な工夫が必要 そのためDDDは、土台作りのための初期投資がかさんだり、 学習コストが高い問題があり、採用是非の見極めが重要
  55. 55. 次回以降何が聞きたい? 1. Domainモデリング手法をもっと詳しく 2. Architecture 3. Domainの分割、Bounded Contextの統合 4. もう聞きたくない

×