An Introduction to Domain Driven Design focusing on the concepts of Bounded Context, Strategic & Tactical Design, CQRS, Ubiquitous Language, Hexagonal Architecture, Event Sourcing, Task - based UIs

1. Introduction to Domain-Driven Design (DDD)
Christos Tsakostas
Athens, 13th December 2013

2. 2
Contents
Motivation
Introduction
Strategic Design
Tactical Design
- Model-Driven Design
- Supple Design and OOP
- Techniques (CQRS, ES, EDA)
Strategic Design Revisited
- Distillation
- Bringing the Strategy together
Wrap-Up

3. MOTIVATION

4. 4
Common Problems
Monolithic Models (Big Ball of Mud)
Anemic Data Models
Relational-Database way of thinking
Communication Difficulties

5. 5
Monolithic Models

6. 6
Anemic Domain Models (cause Memory Loss)

7. 7
Communication Difficulties
Domain Expert Developer

8. 8
DDD Alternative
Monolithic Data Models (Big
Ball of Mud)
Anemic Data Models
Relational-Database way of
thinking
Communication Difficulties
Smaller Independent Domain
Models / Integration
Rich Behavior Objects (OOP
done right)
Persistence Ignorance
Ubiquitous Language

9. INTRODUCTION

10. 10
What is DDD?
It is an Approach to develop software for
- Complex needs
- Evolving models
It is Not a technology or a methodology
It is a Way of Thinking

11. 11
Brief History of DDD
Eric Evans – 2003
DDD Community (http:// www.domaindrivendesign.org)
Jimmy Nilson – 2006
Greg Young – 2008 / 2013
Vaughn Vernon – 2013
P:PubTechnical_documentationDomain Driven Design (DDD)

12. 12
The Business Value of DDD
1. The organization gains a useful model of its domain.
2. A refined, precise definition and understanding of the business is developed.
3. Domain experts contribute to software design.
4. A better user experience is gained.
5. Clean boundaries are placed around pure models.
6. Enterprise architecture is better organized.
7. Agile, iterative, continuous modeling is used.
8. New tools, both strategic and tactical, are employed.

13. STRATEGIC DESIGN

14. 14
Fact
For Complex Systems, most often,
A Single Model Cannot Make it!

15. 15
What do we do?
Multiple Models

16. 16
Strategic Design: The Result

17. 17
Strategic Design – 1. Define the Domain & Identify Subdomains
Life Cycle
Assessment
Substance
Library
Identity and
Access
Subdomain
Subdomain Subdomain
Subdomain
Subdomain
Chesar Domain
IUCLID

18. 18
Strategic Design – 2. Characterize Subdomains
Life Cycle
Assessment
Substance
Library
Identity and
Access
Supporting
Subdomain
Generic
Subdomain
Supporting
Subdomain
Generic
Subdomain
Core Domain
IUCLID
Chesar Domain

19. IUCLID
19
Strategic Design – 3. Define Contexts
Life Cycle
Context
Assessment
Context
Substance
Context
Library
Context
Identity and
Access Context
Chesar Domain

20. IUCLID
20
Strategic Design – 3. Define Contexts / Alternative
Assessment & Life Cycle
Context
Substance
Context
Library
Context
Identity and
Access Context
Chesar Domain

21. IUCLID
21
Strategic Design – 4. Make Contexts Bounded with Context Maps
Life Cycle
Context
Assessment
Context
Substance
Context
Library
Context
Identity and
Access Context
Chesar Domain

22. 9/12/2013 22
Strategic Design – 5. Model Integrity

23. 23
What if initial Strategy is proved to be wrong?
It’s Human Nature…even Inevitable…

24. 24
What do we do?
Redesign – Refactor. Make it Better!
Initial Designs should not be Dogmas.

25. DEFINITIONS

26. 26
Domain (Problem Space)
A sphere of knowledge, influence, or activity (or “The Business”)

27. 27
Domain Model (Solution Space)
A system of abstractions that:
•Describes selected aspects of a domain and
•Can be used to solve problems related to that domain.

28. 28
Problem Space vs Solution Space
Domain Domain Model

29. 29
Context
The setting in which a word or statement appears that
determines its meaning.

30. 30
Bounded Context
A description of a boundary (typically a subsystem, or the work of
a particular team) within which a particular model is defined and
applicable.

31. 31
Context Map
Translation Map between Bounded Contexts.

32. 32
Ubiquitous Language
A language structured around the domain model.
Used by all team members, within a bounded context, to connect
all the activities of the team with the software.
NOT universal!

33. 33
Ubiquitous Language - An Example
Requirements for “Customer”
•Change Personal Name
•Set Postal Address
•Relocate to Postal Address
•Change Home Telephone
•Disconnect Home Telephone
•Set Primary Email Address
•Set Secondary Email Address

34. 34
Data-Driven Implementation

35. 35
DDD Approach incorporating Ubiquitous Language

36. 36
DDD Approach incorporating Ubiquitous Language
Put Behavior (the “What to do”), described in a Ubiquitous way, inside the Object

37. TACTICAL DESIGN

38. Inside a Bounded Context
Tactical Design

39. 39
Model-Driven Design

40. 40
Data-Driven Design: An Invoice

41. 9/12/2013 41
Model-Driven Design – Invoicing Context

42. 42
Tactical Design
Towards a Maintainable and Extensible Model

43. 43
Supple Design

44. Remembering Object Oriented Programming
Tactical Design

45. 45
A - PIE
Abstraction
Polymorphism
Inheritance
Encapsulation

46. 46
S.O.L.I.D.
Single Responsibility Principle (SRP)
Open / Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

47. 9/12/2013 47
Loose Coupling and High Cohesion
Decrease Coupling
Increase Cohesion
Eliminate Inappropriate Intimacy
The Law of Demeter
Tell, Don’t Ask
Say it Once and Only Once

48. 48
Law of Demeter

49. 49
Tell - Don’t Ask

50. 50
Design Patterns
Creational (i.e. Abstract Factory, Singleton)
Structural (i.e. Adapter, Decorator, Proxy)
Behavioral (i.e. Observer or Publish / Subscribe, Visitor)
Concurrency (i.e. Thread Pool, Event-based Asynchronous)

51. ARCHITECTURE
Tactical Design

52. 52
Layered Architecture

53. 53
Dependency Inversion Principle (DIP)

54. 54
Layered Architecture based on DIP

55. 55
Hexagonal Architecture / Ports and Adapters

56. COMMAND QUERY SEPARATION
Tactical Design

57. 57
Single Model

58. 58
Command Query Responsibility Segregation (CQRS)

59. 59
CQRS with Events and Different Storages

60. 60
CQRS -> Command Bus

61. DOMAIN EVENTS
Tactical Design

62. 62
Domain Events / Event Sourcing

63. 63
Domain Events / Event Sourcing

64. 64
Event Sourcing

65. 65
Event Stores: A Time Travel
Logging of Everything
Business Intelligence

66. 66
Views / Projections
Disposable
Even In Memory!

67. 67
Tactical Design: Naming & Modules
A.P.I.
Bounded Context
Domain Model
Ports & Adapters

68. 68
Tactical Design: Naming & Modules
Application Services
Commands
Events
Domain Service
Aggregates

69. 69
Tactical Design:Task-based UIs (Inductive UIs)
Typical CRUD form Task-based

70. STRATEGIC DESIGN
REVISITED

71. 71
Strategic Design - Distillation

72. 72
Distillation: An Abstract Assessment

73. 73
Bringing the Strategy Together

74. WRAP-UP

75. 75
Wrap-Up: Strategy
•In certain cases, one Model cannot make it
•Multiple Models – Integration with Strategic Design
•Ubiquitous Language in Model, Code, Spoken & Written Language
•Be a Good Listener – Understand the Problem Space
•The “worst” Domain Expert is the Best in the World compared to us
•The obvious is not adequate. Focus on Exceptions
•How would / does the Domain function Without Computers?
•Initial Analysis and Design are Not Dogmas – Knowledge comes Slowly
Redesign

76. 76
Wrap-Up: Tactics
•Model-Driven Design as OOP done right
•Focus on What instead of How
•Focus on Behavior (hidden in Verbs) instead of Data (hidden in Nouns)
•Be familiar with, Design Patterns and Principles
•Command Query Responsibility Segregation
•Event – Driven Architecture
•Event Stores
•Hexagonal Architecture / Ports & Adapters
Refactor

77. 77
Strategic, Tactical, DDD, OOP, CQRS, UI, ES, EDA, ….
For the things we have to learn before we can do them,
we learn by doing them.
Aristotle