The document discusses Domain-Driven Design (DDD). It begins with an example of modeling a work schedule and then discusses some key aspects of DDD including ubiquitous language, bounded contexts, tactical patterns for designing domains, keeping domain logic separate from other code, and evolving models over time. It also covers common mistakes like overusing DDD or ignoring strategic design. The document emphasizes learning DDD through experience rather than advice and provides resources for getting started including books, communities, and upcoming events.

1. @ToJans
What is Domain-Driven Design,
and what can you expect from it?

2. The model
Every day of the week
I go to work
2

3. The model
Every day of the week
I go to work
3

4. The model: every day of the week
Day of the week?
- ?
- ?
- ?
- ?
?
- ?
4
?
- ?
- ?
- ?
- ?
- ?
- ?

5. The model: every day of the week
Day of the week?
- Monday to Friday
- 8.30AM to 5.00PM
- Break: 12.30PM, 30mins
- Except Friday:
8.30AM to 3.30PM
- 1 Saturday/month
5
?
- ?
- ?
- ?
- ?
- ?
- ?

6. The model: every day of the week
6
Workday
- Schedule
- Working hours
- Lunch break
- Starting late
- Overtime
- Exceptional Saturday
- ...

7. The model
Every day of the week
I go to work
7

8. The model: every day of the week
Weekday?
- Monday to Friday
- 8.30AM to 5.00PM
- lunch break: 12AM, 30mins
- Except Friday:
8.30AM to 3.30PM
- 1 Saturday/month
8
Every day of the week?
- ?
- ?
- ?
- ?
- ?
- ?

9. The model: every day of the week
Weekday?
- Monday to Friday
- 8.30AM to 5.00PM
- lunch break: 12AM, 30mins
- Except Friday:
8.30AM to 3.30PM
- 1 Saturday/month
9
Every day of the week?
- Official holidays
- Parental leave
- Sick days
- Org closed
- Economical unemployment
- Technical unemployment

10. The model: every day of the week
10
Workday
- Schedule
- Working hours
- Lunch break
- Starting late
- Overtime
- Exceptional Saturday
- ...
Calendar
- Official holiday
- Employee-initiated absence
- Parental leave
- Sick days (Carens day)
- Employer-initiated absence
- Economical/Technical unemployment
- Group holidays
- ...

11. The model
Every day of the week
I go to work
11

12. The model: every day of the week I go to work
12
Workday
Calendar
Schedule
Overtime
Leave
SicknessAbsence
Unemployment
Holiday
ProjectTask
Work log
Billable hour Remote worker
Planning
Deadline
Freelancer Employee
Train
Bike
Car Foot
Deliverable
Customer
Resource

13. The model: every day of the week I go to work
13
Workday
Calendar
Schedule
Overtime
Leave
SicknessAbsence
Unemployment
Holiday
ProjectTask
Work log
Billable hour Remote worker
Planning
Deadline
Freelancer Employee
Train
Bike
Car Foot
Deliverable
Customer
Resource

14. Domain-Driven Design
Domain-Driven Design
Tackling complexity
in the heart of software
Eric Evans - @EricEvans0
14

15. DDD in a tweet
15

16. DDD in a tweet: implicit explicit: language
Ubiquitous language
16

17. DDD in a tweet: implicit explicit: language
17

18. DDD in a tweet
18

19. DDD in a tweet: implicit explicit: boundaries
boundaries
Strategic design
Bounded contexts
19

20. DDD in a tweet: implicit explicit: boundaries
Islands
Data ownership
Contracts
Dependencies
Up- & downstream
Of the shelf or custom built
DDD or not
20

21. DDD in a tweet: implicit explicit: boundaries
21
InfoQ article by
Alberto Brandolini,
a.k.a. @Ziobrando
http://www.infoq.com/articles/ddd-contextmapping
Read it!

22. DDD in a tweet: implicit explicit: boundaries
boundaries
Tactical patterns
How to design the islands?
22

23. DDD in a tweet: implicit explicit: boundaries
Data ownership
Transactional boundaries
Island-specific implementations
Expose behavior, not data
Using ubiquitous language
Aggregates, value objects, repositories, ...
23

24. DDD in a tweet
24

25. DDD in a tweet: implicit explicit: code
Domain logic only
Smallest unit possible
Human-readable
25

26. DDD in a tweet: implicit explicit: code: an example
public Catalog(IQueryACatalog Queries, IChangeACatalog Changes,IGenerateProductIds ProductIdGenerator) {
this.Queries = Queries;
this.Changes = Changes;
this.ProductIdGenerator = ProductIdGenerator;
}
public void RegisterProduct(ProductId Id, IEnumerable<FareZone> FareZones) {
Guard.Against<TooManyFareZonesException>(FareZones.Count() > 3);
Guard.Against<DuplicateProductIdException>(Queries.IdExists(Id));
if (Id == ProductId.Empty) Id = ProductIdGenerator.Next();
Changes.ProductRegistered(Id);
}
public void RegisterSubscription(ProductId Id, IEnumerable<FareZone> FareZones, PaymentSchedule Schedule) {
Guard.With<PaymentScheduleRequiredException>(Schedule != PaymentSchedule.Empty);
RegisterProduct(Id, FareZones);
}
26

27. DDD in a tweet: implicit explicit: code: an example
[TestMethod]
public void should_contain_a_product_when_it_is_registered() {
Catalog.RegisterProduct(a_product_id, some_fare_zones);
Queries.IdExists(a_product_id).ShouldBe(true);
}
[TestMethod, ExpectedException(typeof(DuplicateProductIdException))]
public void should_fail_when_registering_an_existing_id() {
Changes.ProductRegistered(a_product_id);
Catalog.RegisterProduct(a_product_id, some_fare_zones);
}
[TestMethod, ExpectedException(typeof(TooManyFareZonesException))]
public void should_fail_when_registering_too_many_fare_zones() {
Catalog.RegisterProduct(a_product_id, too_many_fare_zones);
}
[TestMethod]
public void should_succeed_when_registering_a_product_with_an_empty_product_id() {
Catalog.RegisterProduct(ProductId.Empty, some_fare_zones);
Queries.IdExists(a_fake_ProductIdGenerator.IdToReturn);
}
27

28. DDD in a tweet
28

29. DDD in a tweet: evolve your model
“All models are wrong,
but some are useful”
George E.P. Box
29

30. DDD in a tweet: evolve your model
“Software is a learning process,
working code is a side effect”
Alberto Brandolini - a.k.a @Ziobrando
30

31. DDD in a tweet: evolve your model: modellathon
Kazachstan
Education system
pic by
Stijn Volders
a.k.a. @ONE75
31

32. DDD in a tweet: evolve your model
“Il semble que la perfection soit atteinte
non quand il n'y a plus rien à ajouter,
mais quand il n'y a plus rien à retrancher.”
Antoine de Saint-Exupéry
32

33. DDD: common mistakes
33

34. DDD: common mistakes
Using DDD everywhere
Ignoring strategic design
Sharing state or code
BDUF
Frameworks vs libraries
Selling DDD
DDD is evolving (f.e. CQRS-style)
34

35. DDD: the biggest mistake
How do I … ?
35

36. DDD: avoid the biggest mistake
“Ask for experience,
not for advice”
Yves Lorphelin, a.k.a. @YLorph
36

37. DDD: how to get started
“A journey of a thousand miles
begins with a single step”
Lao Tzu
37

38. DDD: how to get started
The books
38

39. DDD: how to get started
and...
Go to Julie Lerman’s talk later today:
“Domain-driven design for the Database Driven-Mind”
room 3 - 11.30AM
(Author of http://bit.ly/PS-DDD)
39

40. DDD: how to get started
Newsgroups:
Yahoo: Domain-driven design / Google: DDD-CQRS
Communities:
@DDDBE / #CQRSBeers
Events:
DDD eXchange London - Friday, June 12th 2015
AND … <DRUMROLL>
40

41. DDD: how to get started
41

42. Questions
http://tojans.me - @ToJans
42

43. 43
A big thank you to our partners
Gold Partners
Silver & Social Partners
Platinum Partners