Implementing Domain-Driven Design: Part 1

1. Implementing Domain-Driven Design Part 1: Getting Started with DDD 神原淳史 @atsukanrock 2015/08/07 今だから学びたい！DDD (Sansan .NET勉強会 #10)

2. 自己紹介 • 神原淳史 @atsukanrock https://github.com/atsukanrock • Sansan株式会社 (2014年11月から) アバナード株式会社 (2011年7月～2014年10月) • Software Developer Domain-Driven Design / .NET / C# / Azure Cloud (´･ω･`)

3. 今日のお題は… Today’s Contents

4. DDD: Domain-Driven Design

5. IDDD: Implementing DDD

6. From DDD to IDDD DDD published in 2004 IDDD published in 2013 コンセプトを提示具体的な設計、Do / Don’tを提示ベーシックでやや古いアーキテクチャ DDD発刊以降に出てきたアーキテクチャも導入こいつの紹介

7. Table of Contents • なぜDDDを採用するのか (3分) • いつDDDを採用するのか (2分) • IDDDの全体像 (5分) • DDDのモデリング手法 (2分) • Entity (5分) • Value Object (資料のみ) • 少し複雑な例 (Application Service) (5分) • まとめ (3分)

9. なぜDDDを採用するのか Why do we employ DDD?

10. DDDならできますできること効果 Domain Expertsが持つ業務知識をモデル化 • 個々のDomain Expertに分散していたノウハウの共有 • 担当者が変わってもすぐに使える開発生産性の向上 ※システムが複雑な場合に限る • 加速する事業環境の変化に素早く対応 Domain Expertsですら気付かなかった新たな知見の発見 ∵ (なぜならば) モデル化することで: • 「すぐに」「何度でも」シミュレーション可能 • 抽象化により本質が見える • 単なる業務自動化でなくシステムが事業を引っ張る

11. 前提 • Domain Expertsはチームの一員となる • Agile / Scrum • Domain Expertsとチームは共通の言語 (Ubiquitous Language) 、共通のモデルを使って会話する • 「お客には設計の話なんてするな」ではない

12. とかゆってるけど • Domain Expert is どこ • チームの一員になってくれてモデルの話ができるひとって… • DDDはCore Domain (事業差別化領域) に適用してこそ最大の効果 • 「どの領域をシステム化するか」の選択権って…

13. DDDの本質の実践は困難…

14. それでも自社サービスなら… • サービスの根幹部分がCore Domainになる • Domain Expertsには自分たちがなる • 外部アドバイザーとかは居るかもしれない

16. いつDDDを採用するのか When to employ DDD

17. 向き不向きがあります複雑単純長寿短命 DDD 逃げる勇気 Access VBA とか？ Transaction Script / Table Module

18. The DDD Scorecard from IDDD • 一言で言うと: DDDは複雑で長寿なシステムの場合に使うべきもの • CRUD中心のシステムなら Scaffoldingとかで作れば良い • あと、ゲームとか証券とかにはたぶん向かない

19. 向き不向きがあります複雑単純長寿短命 DDD 逃げる勇気 Access VBA とか？ Transaction Script / Table Module 実際のシステム

20. 私見ですが • システム全体がDDDの使用が適切な特性を持っているわけではない (おそらくほぼ全てのシステムに言える) マスタ管理とか、単純なのがあるはず • DDDを採用するのは一部のCore Domainに絞って、残りはScaffoldingとかTransaction Scriptで作れば良い混ぜる勇気

22. IDDDの全体像 The whole picture of IDDD

23. ざっくり言うと • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーション

24. 今回は時間の都合上 • 概論 (Why / When / How) • Domainの分割、Bounded Context • Architecture • Domainモデリングの手法 • Bounded Contextの統合 • アプリケーションここと (説明済み) ここ (の一部) だけ

25. IDDDは盛り沢山なので… 残りは次回以降に!! …だけどちょっとだけ

26. Domainの分割、Bounded Context • システム化対象領域をいかに分割するか • (今流行りの) Microservice にも通じる考え方

27. Architecture ※私の大好物 • Layers • Dependency Inversion Principle • Hexagonal / Ports and Adapters • Service-Oriented / REST • CQRS: Command-Query Responsibility Segregation • Event Sourcing and more…

29. DDDのモデリング手法 DDD style modeling technique

30. オブジェクトおよび概念 • Entity • Value Object • Service • Domain Event • Module • Aggregate • Factory • Repository New in IDDD

31. 正しく知り、使うことで • Domainの知識がモデルに集約される • UI側に散ったりしない • 不純物が混じらない • トランザクション • セキュリティ • アプリケーション要件 • SOLID Principlesを守れる • オブジェクト指向の超大事な原則5つ

33. Entity The core of domain modeling

34. A Poor Entity getter / setterのみのプロパティが並ぶ (単なるデータの入れ物) • SprintIdとStatusを合わせて設定するという知識がクライアントに • 実際にはValidationとかDB保存とかもっとやることが多い

35. A DDD Style Entity getter / setterのみのプロパティは消えた適切なValidation Domainの知識

36. Entity in IDDD • Identity大事 • 何をIdentityとするか • Identityが満たすべき要件 • Entityの生成 • コンストラクター • Factory

37. Entity in IDDD • Validation • Value Objectで守る • プロパティのSetterで守る • Validatorを切り出す • DBに行くようなValidationはしない (例: ユニークチェック) • Change Tracking

39. Value Object To enrich your entities

40. もしValue Objectがなかったら EntityにDomainの知識を持たせる。間違ってはいないが… プロパティがわらわらあって何かぼやけてる感じ ∵ ひとまとまりのコンセプトが他のコンテキストに混じってしまっている

41. A sample Value Object Domainの知識

42. Value Objectのある世界ひとまとまりのコンセプトが Value Objectにまとまった

43. Value Object in IDDD • Identityを持つモノでなく、等価交換可能 • Immutable • Value Equality (implements IEquatable<T>) • Side-Effect-Free Behavior • Persisting Value Objects • DB等への保存

44. Value Object in IDDD • Entity’s Identity as Value Object • 単なるString等でなくXxxIdクラスを作る • (↑とはいえ) 何でもかんでもValue Objectにはしない • 複数の属性もしくは振る舞いを持つものだけ • それ以外はプリミティブ型で済ます

46. 少し複雑な例 (Application Service) A little bit complex example of Application Service

47. A sample Application Service DI前提 (changed from DDD) Query Service ※後述 Application Service • Domain Modelを使ってアプリケーションのトランザクションを実行 • 必要なセキュリティを実装

48. Domain Model in Application Service Entity Repository Value Object Service

49. Query Service? SQLベタ書き Application Layer of Hexagonal Architecture ※後述 • CQRS (次回以降のお話) のQuery Command (参照のみ) • データアクセスがRepositoryだけだとアプリケーション向けのQueryがしんどい (Join とかあって) EntityでなくData Transfer Objectを返す

50. Hexagonal Architecture? • 一言で言うと: Domain Modelさえクリーンに保てば、後は作りやすいように作ればおｋ • DI (IoC) が前提になる • 詳しくは次回以降に…

52. まとめ Wrap up

53. まとめ • DDD採用の目的: システムの価値を上げる • そのために、Domainモデリングの手法を学ぶ • IDDDが具体的な指針を示した

54. 捕捉 • 図、サンプルコードは全てIDDDから拝借した https://github.com/VaughnVernon/IDDD_Samples_NET • 実はDomain Modelをクリーンに保つには、それ以外のところ (例えばDBアクセス周り) に相当な工夫が必要そのためDDDは、土台作りのための初期投資がかさんだり、学習コストが高い問題があり、採用是非の見極めが重要

55. 次回以降何が聞きたい? 1. Domainモデリング手法をもっと詳しく 2. Architecture 3. Domainの分割、Bounded Contextの統合 4. もう聞きたくない

Implementing Domain-Driven Design: Part 1

You are reading a preview.

Check these out next

Implementing Domain-Driven Design: Part 1

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to Implementing Domain-Driven Design: Part 1 (20)

Recently uploaded (20)