DDD and Microservices: Like Peanut Butter and Jelly by Matt Stine at SpringOne Platform 2019

1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Matt Stine (@mstine)
Global Field CTO / Chief Architect
mstine@pivotal.io
http://mattstine.com
DDD and Microservices:
Like Peanut Butter and Jelly

2. What is the
State of Microservices
in 2019?

3. We built the WRONG microservices!

4. We built TOO MANY microservices!

5. We DIDN’T REALLY NEED microservices!

6. We created the SAME OLD ARCHITECTURE
with microservices!

7. what we’ve got
here is failure to
DESIGN

8. WHERE ARE THE
SEAMS?

9. https://builttoadapt.io/whats-your-decomposition-strategy-e19b8e72ac8f

10. DOMAIN
MODEL
TECHNICAL
ARCHITECTURE

11. MICROSERVICES
DOMAIN
DRIVEN
DESIGN

12. DDD 101
DOMAIN MODELING

13. The Ubiquitous Language
The Most Important Thing

14. When discussing the domain, and I use a term,
and you use exactly the same term, we mean
precisely the same thing.

15. Everybody Develops and Uses It
!Data
Scientist
"Business
Owner
#Designer
$Developer
%Product
Manager
&Operator
'Tester

16. It is Used Everywhere
Verbal Discussions
Diagrams Code
Documents User Stories

17. Where It Exists
"
"
"
$
$
$
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
"
"
"
$
$
$
顧客
顧客
顧客
顧客
顧客
顧客
"
"
"
$
$
$
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक
Bounded Contexts

18. Strategic Design - the View from 35,000 FEET

19. Finding THE
SEAMS

20. Integrating
the
Pieces
"
"
"
$
$
$
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
"
"
"
$
$
$
顧客
顧客
顧客
顧客
顧客
顧客
"
"
"
$
$
$
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक

21. What Came First?
Bounded
Context
Ubiquitous
Language

22. Global Ubiquitous Language?
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
"
"
"
$
$
$
顧客
顧客
顧客
顧客
顧客
顧客
"
"
"
$
$
$
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक
"
"
"
$
$
$

23. Essential Differences
"
"
"
$
$
$
"
"
"
$
$
$
An Order is
something for which
we process Payments!
An Order is
something we ship to
the appropriate
address!
"
"
"
$
$
$
An Order is
something we fulfill
from warehouse
inventory!

24. Bound and Embrace the Differences
Shipping Context
"
"
"
$
$
$
Payments Context
"
"
"
$
$
$
An Order is
something for which
we process Payments!
An Order is
something we ship to
the appropriate
address!
Fulfillment Context
"
"
"
$
$
$
An Order is
something we fulfill
from warehouse
inventory!

25. Payments Context
Fulfillment Context
Shipping Context
The Language is Scoped
Internally
Consistent
Internally
Consistent
Internally
Consistent
Undefined Undefined
Undefined

26. Context
Mapping

27. Connecting
the
Contexts
"
"
"
$
$
$
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
πελάτης
"
"
"
$
$
$
顧客
顧客
顧客
顧客
顧客
顧客
"
"
"
$
$
$
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक
ग्राहक

28. We define mappings on the basis of language.

29. Partnership
"$
ग्राहकग्राहक πελάτηςπελάτης
"$

30. Shared Kernel
πελάτηςπελάτης
"$
"$
ग्राहकग्राहक
顧客

31. Customer-Supplier
"$
ग्राहकग्राहक πελάτηςπελάτης
"$
Upstream
Downstream

32. Conformist
"$
顧客顧客 顧客顧客
"$
Upstream
Downstream

33. Anticorruption Layer
"$
ग्राहकग्राहक πελάτηςπελάτης
"$
Upstream
Downstream
ACL

34. Open Host Service
"$
ग्राहकग्राहक πελάτηςπελάτης
"$
Upstream
Downstream
Think API!
OHS

35. Published Language
"$
ग्राहकग्राहक πελάτηςπελάτης
"$
Upstream
Downstream
Think API!
PL

36. Separate Ways
"$
ग्राहकग्राहक πελάτηςπελάτης
"$

37. Tactical Design?
Now it’s time to start speaking the
Ubiquitous Language within each Bounded Context.
■ Business Invariants
■ Policies
■ Transactions
■ State
■ Persistence

38. The Central Concept
Aggregate
A cluster of objects
treated as a single unit.
Often modeled as a
state machine.
The atomic unit for any
transactional
behavior.
Only accessed through its
Root Entity.
Responsible for maintaining
any/all business invariants.
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

39. Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

40. Entity An object whose state changes over time,
but whose identity remains the same.
( ) *+
{
id: 1,
name: “Joe”,
age: 0
}
{
id: 1,
name: “Joe”,
age: 8
}
{
id: 1,
name: “Joe”,
age: 35
}
{
id: 1,
name: “Joe”,
age: 60
}

41. Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

42. Value
Object
+
{
id: 1,
name: “Joe”,
age: 35,
address: <PTR>
}
🏠 🏡{
street: “123 Vine St.”,
city: “Memphis”,
state: “TN”
}
{
street: “123 Long Rd.”,
city: “Memphis”,
state: “MI”
}
An object whose identity is inseparable
from its value.

43. Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

44. Order
Business Invariant: “Can only place an order if it contains at least one line item.”
Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object
Protect business invariants
inside Aggregate boundaries.
Line Item
Place
Order

45. Design Small Aggregates.
Example credit: Vaughn Vernon, Implementing Domain-Driven Design
Large Cluster
Aggregate
SprintRelease
Backlog
Item
Product
(Root)
Multiple
Aggregates
Product
(Root)
Backlog
Item
(Root)
Sprint
(Root)
Release
(Root)
Product ID
"
%
"
%
Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

46. Reference Other Aggregates
by Identity Only.
Line Item
Order
(Root)
Product
(Root)
Composition
Product
(Root)
Product IDLine Item
Order
(Root)
Reference
Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

47. Update Other Aggregates
Using Eventual Consistency.
Customer Shipping Customer
{
id: 1,
first_name: “Joe”,
last_name: “User”
}
{
id: 1,
name: “Joe User”
}
{
id: 1,
first_name: “Joseph”,
last_name: “User”
}
{
id: 1,
name: “Joseph User”
}
Customer Updated!
Domain Event
Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object

48. Domain Event
A Record of a Business-Significant Occurrence
within a Bounded Context.
"$
ग्राहकग्राहक
πελάτηςπελάτης
"$
Aggregate
Aggregate
Aggregate
OrderPlacedEvent
ItemAddedToOrderEvent
OrderCanceledEvent
OrderPaidEvent
OrderFulfilledEvent
OrderDeliveredEvent

49. Application Services
The First Client to Your Domain Model.
Application
Service
Order
{
id: 1
} Place Order
Repository
Find by ID
Place Order

50. HEXAGONAL ARCHITECTURE
(or Ports and Adapters)
TECHNICAL ARCHITECTURE

51. Application Service
Domain
Model
Adapter
Port
Port
Port
Port
Port Port
Adapter
Adapter
Adapter
Adapter
Hexagonal
Architecture
■ Domain Model (Aggregates, etc.)
wrapped by an Application Service
■ Ports represent generic
entry/exit points (interface)
■ Adapters represent specific
entry/exit implementations (class)

52. Adapter
Port
Port
Port
Port
Port Port
Adapter
Adapter
Adapter
Adapter
Hexagonal
Architecture
Order
(root)
Line Item
Order ID
Order
Repository
Order Placed
■ Domain Model (Aggregates, etc.)
wrapped by an Application Service
■ Ports represent generic
entry/exit points (interface)
■ Adapters represent specific
entry/exit implementations (class)
Application Service

53. Adapter
Port
Port
Port
Port
Port Port
Adapter
Adapter
Adapter
Adapter
Adapter
Adapter
Adapter
Adapter
REST
SOAP
AMQP
AdapterAdapterKafka
JDBC
■ Domain Model (Aggregates, etc.)
wrapped by an Application Service
■ Ports represent generic
entry/exit points (interface)
■ Adapters represent specific
entry/exit implementations (class)
Application Service
Order
(root)
Line Item
Order ID
Order
Repository
Order Placed
Hexagonal
Architecture

54. Request / Response
HTTP
Outbound
Gateway
HTTP
Inbound
Gateway

55. Fire and Forget
AMQP
Outbound
Gateway
AMQP
Inbound
Gateway
RabbitMQ

56. Queues / Load Balancing
AMQP
Outbound
Gateway
AMQP
Inbound
Gateway
RabbitMQ
AMQP
Inbound
Gateway

57. Publish - Subscribe
Kafka
Outbound
Gateway
Kafka
Inbound
Gateway
Kafka
Kafka
Inbound
Gateway

58. Introducing Persistence
Cassandra
PostgreSQL
Repository
Cassandra
Repository
JDBC
Repository

59. MICROSERVICES
TECHNICAL ARCHITECTURE

60. A Seattle book store deploys code, on
average, every second.

61. So what are microservices anyway?
Interlude

62. Microservices are independently evolvable
and autonomously deployable services that
govern their own state and incorporate
resiliency patterns.

64. The primary role of microservices is to
provide a useful quantum of DevOps
and Continuous Delivery.

65. DDD DECOMPOSITION
STRATEGY
MAKING THE SANDWICH

66. But what microservices should we create?
The Right Questions

67. How many microservices should we have?
The Right Questions

68. How big should our microservices be?
The Right Questions

69. The Golden Rule
Microservice
Aggregate
Entity
EntityEntity
Value
Object
Value
Object
Value
Object
≤
"$
ग्राहकग्राहक
Aggregate
Aggregate≤
Aggregate ≤ SizeOf(Microservice) ≤ Bounded Context

70. GLUING IT ALL TOGETHER
MAKING THE SANDWICH

71. Deployment Topology Spectrum
Big
Ball
of
Mud
Monolith Modular Monolith Microservices

72. Modules are Modules
■ High Cohesion
■ Low Coupling
■ Business Capability Focus
■ Bounded Contexts / Aggregates
■ Data Encapsulation
■ Substitutable
■ Composable
■ Individually Deployable
■ Individually Upgradeable
■ Individually Replaceable
■ Individually Scalable
■ Heterogeneous Tech Stacks
Modular Monolith Microservices

73. The criteria for effectively creating modules
inside of a monolithic codebase translates
into effective criteria for microservice
modularity.

74. We want to maintain a modular structure that
can exist in either a monolithic or
microservices architecture.

75. Transforming How The World Builds Software
© Copyright 2018 Pivotal Software, Inc. All rights Reserved.
Matt Stine (@mstine)
Global Field CTO / Chief Architect
mstine@pivotal.io
http://mattstine.com