Presentation of the "Introduction to Domain Driven Design" talk, on the 1st of March 2017.

1.
Introduction to Domain Driven
Design

2. Frank Levering
• PHP Developer
• DevMob

3. Quality software
• Writing tests
• Using design patterns
• Manual testing
• SOLID

4. Quality software doesn’t give
an insurance for a quality
software model

5. Code example
Date - Name

6. It saves a customer no
matter what, awesome right?

7. This model is suffering from
Anemia

8. We have no idea under what
business situations this
method is used

9. And it even gets worse

10. Code example
Date - Name

11. Can we really test this?

12. DDD helps you creating a
more high-quality software
model

13. It helps you create software
that makes sense to the
business

14. You would be making software that
is as close as possible to what the
business leaders and experts would
create if they were the developers

15. Disclaimer
• A domain is not DNS or
anything internet related
• Domain is the area your
business relies

16. So how does DDD work?
• Strategic design
• Tactical design

17. We will mostly be talking
about strategic design today

18. Key concepts of strategic design
• Domain experts
• Ubiquitous language
• Core Domains, Subdomains
and Domain Models
• Bounded Contexts

19. Not doing any strategic
design results in doing DDD-
Lite

20. Domain experts

21. Bringing domain experts and
developers to the same playing
field which produces software
that makes sense to the business

22. Introducing Ubiquitous
language

23. It’s not the language of the
business

24. It must not adopt industry
standard terminology

25. It’s also not the language
used by domain experts

26. It’s a shared language
developed by a team, a team
composed of both domain
experts and developers

27. Ubiquitous language
develops on the way

28. No translations between the
domain experts, software
developers and the software

29. Date - Name

30. Ubiquitous language is
important when designing
the behaviour of objects

31. Code example
Date - Name

32. Code example
Date - Name

33. This was kind of an extreme
example

34. Code example
Date - Name

35. Code example
Date - Name

36. Domains

37. A domain, in the broad
sense, is what an
organisation does

38. But the term domain is a bit
overloaded

39. So let’s use Core Domain
and Subdomains

40. The whole Domain of the
organisation is composed of
Subdomains

41. Retailer example
Date - Name

42. But what is the Core
Domain?

43. Generic vs Supporting
Subdomains

44. Why is this so important?

45. Developers like to focus on
the technical part of a
product

46. We focus on Entities, Value
Objects, Services,
Aggregates

47. By doing that, we blend core
concepts with generic ones

48. Causing the creation of two
models into one

49. Date - Name

50. Agile PM tool example
Date - Name

51. Focus on Core Domain

52. The Domain is your problem
space

53. Domain Model

54. What is the Domain Model?

55. The Domain Model is your organised
and structured knowledge of the problem.
• It should represent the
vocabulary and key concepts
of the problem domain
• It should identify the
relationships among all of the
entities

56. It could be a diagram

57. Or written documentation

58. But in our case..
It’s a software model of the very
specific domain you are working in

59. It should be accessible and
understandable by everyone
involved in the project

60. Bounded Contexts

61. Bounded Context is an
explicit boundary in which a
domain model exists

62. The boundary is created because
each of the model’s concepts
inside, with its properties and
operations, has a special meaning

63. Example with Bounded
Contexts
Date - Name

64. Inside a Subdomain, you can
have multiple Bounded
Contexts

65. A Bounded Context should be
as big as it needs to be in order
to fully express its complete
Ubiquitous Language

66. Concepts that are not truly
part of the domain should be
factored out

67. Naming a Bounded Context

68. So why should you do DDD?

69. Bringing domain experts and
developers to the same playing
field which produces software
that makes sense to the business

70. You would be making software that
is as close as possible to what the
business leaders and experts would
create if they were the developers

71. Learning more about the
business, both domain
experts and developers

72. No translations between the
domain experts, software
developers and the software

73. Centralizing knowledge is
key

74. Thank you