Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1SWzQGQ. Eric Evans introduces a few strategic design concepts and explains how they apply to development of microservices, as a tool for teams trying to grow large systems more coherently. Filmed at qconlondon.com. Eric Evans is the author of "Domain-Driven Design: Tackling Complexity in Software." Eric now leads Domain Language, a consulting group which coaches and trains teams applying domain-driven design, helping them to make their development work more productive and more valuable to their business.

1. DDD & Microservices
At last, some boundaries!
Eric Evans
@ericevans0
domainlanguage.com
Complex business logic
Domain-driven Design
Domain modeling
Ubiquitous language

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/ddd-microservices-2016

3. Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon London
www.qconlondon.com

4. You say ‘bandwagon’ like it’s a bad thing!
Adrian Cockcroft

5. Why do I like microservices?
• Autonomous teams with isolated implementation.
• Acknowledge the rough and tumble of enterprises.
• Cattle not pets.
• A philosophical break from the past — gives us a
chance to shake assumptions.
• But! Different people mean different things.

6. Services and Messages
Sm mm m mm

7. A
m
m
m m
m m
B

8. A
a
b
a a
b b
B
How do they understand the messages?

9. Bounded Context
• context The setting in which a word or statement
appears that determines its meaning
• bounded context The conditions under which a
particular model is defined and applicable.

10. A
a
b
a a
b b
B
partners
A B
Context Map translator
bounded contexts

11. partners
A B
Context Map
A
a
b
a a
b b
B
C
a
a
a

12. Asymmetrical Relationships
Context Name Context Name
relationship
(point toward power)

13. Context Map
A
a
b
a a
b b
B
C
a
a
a
partners
A B
C

14. Context Map
A
a
b
a a
b b
B
C
a
a
a
partners
A B
C
conforms

15. Context Map
partners
A B
C
conforms
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a

16. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
partners
A B
C
conforms
D
AC

17. Context Map
partners
A B
C
conforms
D
AC
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a

18. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
partner
sA B
C
conforms
D
AC
E
conforms

19. Context Map
partner
sA B
C
conforms
D
AC
E
conforms
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
a
a
a

20. Context Map
partner
sA B
C
conforms
D
AC
E
conforms
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f

21. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC

22. There are always
multiple models.
enterprise model
shared database schema
unified field theory
one ring

23. Models need to be clear,
not big.
• Useful models need crisp definitions.
• Definitions require clear context.
• Useful models need simple assertions.
• Assertions require boundaries.

24. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC

25. Context Map
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f

26. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC
BBoM

27. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC
BBoMBBoM

28. Context Map
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC
BBoMBBoM
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E ae ae
F
b
b
ae
ae
ae
f
Fiction!
Map what is.

29. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E ae ae
F
b
b
ae
ae
ae
f
What can be done?
partners
A B
C
conforms
D
AC
E
Fconforms
AC
BBoMBBoM
BBoM

30. Not all of a large system
will be well designed.

31. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E ae ae
F
b
b
ae
ae
ae
f
partners
A B
C
conforms
D
AC
E
Fconforms
AC
BBoMBBoM
BBoM
???
???
Mitigation

32. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E ae ae
F
b
b
ae
ae
ae
f
partners
A B
C
conforms
D
AC
E
Fconforms
AC
BBoMBBoM
AC
AC
BBoM

33. Microservice as
Context Boundary
• Allow high-concept modeling in a messy world.
• Allow specialized models for distinct problems.
• Mitigate consequences of design mistakes.
• Acknowledge the rough and tumble of enterprises.
• But…
• Very interesting stuff is not inside the services!

34. Interchange context

35. Context Map
A
a
b
a a
b b
B
C
a
a
a
D
a
a
a
E a a
F
b
b
a
a
a
f
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC

36. Context Map
partners
A B
C
conforms
D
AC
E
conforms
Fconforms
AC
A
a
b
a a
b b
B
C
i
i
i
D
i
i
i
E i i
F
b
b
i
i
i
f

37. Context Map
A
a
b
a a
b b
B
C
i
i
i
D
i
i
i
E i i
F
b
b
i
i
i
f
partners
I
B
C
conforms
D
AC
E
conforms
Fconforms
AC
AAC

38. `
• A relatively generic data model for sharing.
• or…
• A place to model protocols of interaction.
• Modeling and design of higher-level solutions.
• A domain language tuned to these purposes.

39. Interchange Context
• Expressed in terms of service interfaces/messages.
• Distinct from the objects/functions of the internals of a
service.
• Prevents distortion/freezing of early-dominant contexts.
• Gives big-picture understanding when we have many
services.
• Usually more than one! (Avoid enterprise model.)

40. Why not logical boundaries?
• Smart people I respect point out that most of what I
want is the logical partitioning of the system.
• We’ve had decades to get that to work.
• Some techniques are too subtle to survive the
rough and tumble.

41. Wrap up
• Subtle design (such as DDD) requires concrete
boundaries. Microservices have them.
• Proliferation of services recreate some of the old
problems.
• Context Maps help visualize and communicate
about those problems.
• Modest use of interchange contexts can help
produce coherent sets of microservices.

42. Not all of a large system
will be well designed.

43. DDD & Microservices
At last, some boundaries!
Eric Evans
@ericevans0
domainlanguage.com

44. Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/ddd-
microservices-2016