Introduction to Domain driven Design

1. Paulo Gandra de Sousa
pag@isep.ipp.pt

2. Object-Oriented Design
is about behaviour,
not structure.
2

3. Procedural thinking where Objects are just Plain
data structures devoid of any behaviour, and
behaviour is concentrated in “service” and
“controller” classes.
3

4. 4
 Bounded Context
 Entities
 Aggregate Roots
 Value Objects

5. “The fundamental assumption of
DDD is that human beings are
incapable of building enterprise
applications, but are capable of
understanding small, well-
bounded problems (a "domain").”
https://visualstudiomagazine.com/articles/2015/07/01/domain-
driven-design.aspx
5

6. 6

7. 7

8. First paradigm shift
8

9.  Problema:
 qual é o princípio geral para a atribuição de
responsabilidades aos objetos?
 Solução:
 Atribuir a responsabilidade ao information expert
- a classe que contém a informação necessária
para desempenhar essa responsabilidade
9
GRASP

10. class Employee {
private int number;
private double salary;
private List skil = new ArrayList();
...
public int getNumber() { … }
public void setNumber(int n) { … }
public double getSalary() { … }
public setSalary(double s) { … }
public List getSkills() { … }
public void setSkills(List s) { … }
}
10

11. Segregation of the design decisions that are most
likely to change, thus protecting other parts from
extensive modification if the design decision is
changed.
11

12. An object cannot be constructed neither modified
in a way that it does not hold its internal
consistency.
12

13. class Employee {
public Employee()
...
public void setNumber(int n) { … }
public setSalary(double s) { … }
public void setSkills(List s) { … }
}
 VS
class Employee {
public Employee(int number, double salary) { ... }
...
private void setNumber(int n) { … }
private void setSalary(double s) { … }
public void addSkill(Skill s) { … }
public void removeSkill(Skill s) { … }
}
13

14.  setFirstName(string fn)
 setLastName(string ln)
vs.
 changeName(
string first,
string last)
 setStatus(STATUS st)
 getStatus()
vs.
 activate()
 deactivate()
 isActive()
14

15. 15
Procedural code gets
information then makes
decisions.
Object-oriented code tells
objects to do things.
— Alec Sharp

16. 16

17. 17

18. Second paradigm shift
18

19. One rule
19

20.  Objects wich rich behaviour in the real world
which we would like to track its identity
 Example:
 Student identified by Student Number, NIF,
email
 Product identified by Product Reference
 Sale identified by Invoice Number
20
DDD

21. Class Product{
private ProductID id;
// other attributes of product, e.g., designation,
description, etc.
public Product(String sku, Money price) {…}
public ProductID getProductID() { … }
private void setProductID(string sku) { … }
public boolean equals(Object other) {
if (other==this) return true;
if (!(other instanceof Product)) return false;
return (this.getProductID() ==
(Product)other.getProductID());
}
}
21
Always
constructed in a
valid state
It’s ok to return
one’s identity
No one can change
one’s identity
Object instances refers to
the same real world entity, if
they have the same identity

22. @Entity
Class Product{
// database ID
@ID
@GeneratedValue(strategy=GenerationType.AUTO)
private Long id;
private void setID(Long id) { … }
private Long getID() { … }
// domain ID
private ProductID ref;
public ProductID getProductID() { … }
private void setProductID(ProductID ref) { … }
…
}
22

23.  Problem
 Some objects matter for the value of its
attributes, e.g., Color
 Serve to describe, quantify or classify na Entity
 Solution
 Create immutable objects which are identified by
the equality of its attributes and do not need an
identity
24
DDD

24. class Color {
private final float red;
private final float green;
private final float blue;
public Color(int r, int g, int b) {…}
public float redPercentage() {…}
public float greenPercentage() {…}
public float bluePercentage() {…}
public boolean isPrimaryColor() {…}
// imutable; creates a new object
public Color combinedWith(Color other) {…}
// equality by value
public boolean equals(Object other) {…}
}
25

25. 26
@Embeddable
class Color {
private int red;
private int green;
private int blue;
…
}
@Entity
Class Car {
…
private Color color;
…
}

26. 27
@Entity
class Color {
// database ID not to be exposed to domain
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private int id;
// domain values
private int red;
private int green;
private int blue;
…
// avoid instantiation
private Color() {...}
//factory method
public static Color fromRGB(int r, int g, int b) { … }
}
@Entity
Class Car {
…
@OneToOne
private Color color;
…
}
Factory method hides
the lookup/write to the
DB if necessary.

27. The Domain, SRP and Value Objects
Primitive types are not the best option to represent
domain concepts!
Favour imutability of your objects.
28
Person
«value»
Name
«value»
Address
«value»
NIF
«value»
PhoneNumber
1..*1
1 *
«value»
Email
*

28.  Requirement 321:
 Passwords must be at least 6 characters longs and
have at least one digit
29

29. @Test
public void ensurePasswordHasAtLeastOneDigitAnd6CharactersLong() {
new Password("abcdefgh1");
}
@Test(expected = IllegalArgumentException.class)
public void ensurePasswordsSmallerThan6CharactersAreNotAllowed() {
new Password("ab1c");
}
@Test(expected = IllegalArgumentException.class)
public void ensurePasswordsWithoutDigitsAreNotAllowed() {
new Password("abcdefgh");
}
30
You are actually
doing design

30. @Test
public void ensurePasswordHasAtLeastOneDigitAnd6CharactersLong() {
Password p = Password.valueOf("abcdefgh1");
}
@Test(expected = IllegalArgumentException.class)
public void ensurePasswordsSmallerThan6CharactersAreNotAllowed() {
Password p = Password.valueOf("ab1c");
}
@Test(expected = IllegalArgumentException.class)
public void ensurePasswordsWithoutDigitsAreNotAllowed() {
Password p = Password.valueOf("abcdefgh");
}
31
Taking decisions on
how the code will
work

31. public class Password {
…
public Password(String password) {
if (!meetsMinimumRequirements(password)) {
throw new IllegalStateException();
}
thePassword = password;
}
private boolean meetsMinimumRequirements(String password) {
if (Strings.isNullOrEmpty(password)
|| password.length() < 6)
|| !Strings.containsDigit(password))
{
return false;
}
return true;
}
32

32. All methods of a domain object should handle
domain entities and value objects only; no primitive
types.
void setName(String name)
vs.
void setName(Name aName)
Provide a convenience valueOf() method to convert
from primitives read from the outside (e.g., UI, DB)
Class Name {
public static Name valueOf(String name) {…}
}
33

33.  Problem:
 Some business operations are not naturally
placed in a certain domain object
 Solution:
 Create a service object that handles only that
operation and coordinates the necessary domain
objects.
34
DDD

34.  Money transfer between two accounts:
Account.transferTo( Account other,
Money amount
)
vs.
TransferService.transfer( Money amount,
Account from,
Account to
)
35
DDD

35. 36

36. 1. An object is created
2. The object is used
3. It must be persisted for later use
4. Later, the object is reconstructed from
persistence
5. It is used (provably changed)
6. It is stored back again for later use
7. …
37

37. When creation of an entire, internally consistent
aggregate, or a large value object, becomes
complicated or reveals too much of the internal
structure, factories provide encapsulation.
38
DDD

38.  Problem:
 How to hide the details of persisting and
reconstructing an object while keeping the
domain language?
 Solution:
 Query access to aggregates expressed in the
ubiquitous language
 Abstract the persistence of an object in a
Repository class that behaves as a list
39
DDD

39. Another paradigm shift
40

40. 41
N-to-M
relationships
are hard

41. 42
• Remove
unnecessary
associations
• Force traversal
direction of
bidirectional
associations
• Reduce cardinality
by qualification of
the association
we are still left
with a tangle of
interconnected
objects...

42.  Some objects are closely related together
and we need to control the scope of data
changes so that invariants are enforced
 Therefore
 Keep related objects with frequent changes
bundled in an aggregate
 control access to the “inner” objects thru one
single “root” object
43
DDD

43. 44
Legend:
• Account
aggregate
• Customer
aggregate
Address is a value
object so it can be
freely shared among
several aggregates

44.  Efficient aggregate design is hard
 Imagine the relationship between an account
and its movements
 Are movements part of the Account
aggregate?
45

45. Account
Movement
Account
Movement
Account Account
Movement
46
VS.

46. 47

47. 48
 Entities,Value objects and Aggregates are
about things
 Services are about operations
 But, what happens in the system is also
important.

48.  Some things that happen in the domain are
worth noting.
 Therefore
 Model activity in the domain as a series of
discrete events represented as a domain object.
49
DDD

49.  A domain event might be of interest to some
object.
 Therefore
 Make the interested object an observer of the
event’s issuing party.
50
GoF

50. 51
fonte: Design Patterns: Elements of Reusable Object-Oriented Software
GoF

51.  A nice “global”Watchdog
 Event dispatcher
 Perfect for publish-subscribe technologies
 Specially for out of process observers
52

52. 53
Aggregate X
«root»
X
«Entity»
Y
«Value»
A
«event»
E1
publishes
Aggregate V
«entity»
W
«Value»
D
«root»
V
«Value»
F
«service»
Watchdog/dispatcher
consumes
observes
Aggregate Z
observes
consumes

53. 54

54. 55
FormUI
-memberName
+OnOkClick()
UseCaseController
-memberName
+doUseCaseStep()
EntityFactory
-memberName
+create(): Entity
Entity
-memberName
-publishEvent(EntityEvent)
+doBusinessLogic()
«interface»
EntityRepository
+save(e: Entity)
SubEntity
-memberName
+doBusinessLogic()
RepositoryFactory
-memberName
+entityRepository()
SqlDbEntityRepository
+save(e: Entity)
EntityEvent
-memberName
+getState()
publishes
ObserverEntity
-memberName
+doBusinessLogic()
+onEventPublished(EntityEvent)
consumes

55. 56

56. 1. Getters and Setters are Evil
2. Entities, Value Objects
3. Aggregates, Domain Events
57

57. 58https://blog.pragmatists.com/refactoring-from-anemic-model-to-ddd-880d3dd3d45f

58.  Anemic Domain Model, Martin Fowler.
http://martinfowler.com/bliki/AnemicDomain
Model.html
 Why getters and setters are Evil.Allan Holub.
http://www.javaworld.com/article/2073723/co
re-java/why-getter-and-setter-methods-are-
evil.html
 Tell, don’t ask.The Pragmatic Programmers.
https://pragprog.com/articles/tell-dont-ask
60

59.  Domain Driven Design (2004). Eric Evans
 Domain Driven Design reference (2011). Eric Evans.
http://domainlanguage.com/ddd/patterns/DDD_Refer
ence_2011-01-31.pdf
 Implementing Domain Driven Design (2013).Vernon
Vaughn.
 Services in Domain Driven Design (2008) Jimmy
Bogard.
http://lostechies.com/jimmybogard/2008/08/21/servic
es-in-domain-driven-design/
 Effective aggregate Design (2011)VernonVaughn.
http://dddcommunity.org/library/vernon_2011/
61

60.  Design Principles and Design Patterns.
Robert Martin.
http://www.objectmentor.com/resources/arti
cles/Principles_and_Patterns.pdf
 Applying UML and Patterns; Craig Larman;
(2nd ed.); 2002.
 Design Patterns-Elements of Reusable
Object-oriented Software, Gamma et al.
(Gang of Four)
62