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.
QCon London: Mastering long-running processes in modern architectures
DDD and Microservices: At Last, Some Boundaries!
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
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.
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.
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
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!
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.