The idea of cutting one’s application into minimal pieces – a.k.a. (micro-) sercives- which communicate with each other has some merit. Theoretically this sounds quite easy but it is actually a challenge. The trick is to find the correct size for the single services. But how can we cut the services correctly? How can we manage not to pick the business logic to pieces and lose sight of the whole entity? And what does the communication between the sercives look like? Based on an experience report, this session shows how Domain Driven Design can help answering these – and even some more - questions.

1. Size does(n’t) matter!
How to cut a
(Micro)Service correctly?
Lars Röwekamp
CIO New Technologies
#wissenteilen
@mobileLarson
@_openKnowledge

2. Microservices
Monolithic Design
Microservice Design
Surviving Service Design

3. „Monolithic Design”

4. What’s your problem?
‣ Building features takes too long
‣ Architectural quality has degraded
‣ Technical debt is well-known and not addressed
‣ „-ility“ problems abound
‣ Deployment is way to complicated and slow
‣ Scalability has reached its limit
‣ Replacement would be way too expensive
#WISSENTEILENOFFENKUNDIGGUT

5. „For a monolithic to change
all must agree on each
change.
Each change has
unanticipated effects
requiring testing beforehand.“
What’s the problem?
#WISSENTEILENOFFENKUNDIGGUT

6. Monolithic „Module“ Release
What’s the problem?
#WISSENTEILENOFFENKUNDIGGUT

7. Monolithic „Module“ Release
What’s the problem?
#WISSENTEILENOFFENKUNDIGGUT

8. Monolithic „Module“ Release
What’s the problem?
#WISSENTEILENOFFENKUNDIGGUT

9. Monolithic „Module“ Release
Scary!
What’s the problem?
#WISSENTEILENOFFENKUNDIGGUT

10. What’s the problem? You want to be here.
#WISSENTEILENOFFENKUNDIGGUT

11. Load Balancer M
ulti Tenancy
Microservices
What’s the problem? You want to be here.
#WISSENTEILENOFFENKUNDIGGUT

12. @Runtime
@
Runtim
e
a.k.a.„TimetoMarket“
What’s the problem? You want to be here.
#WISSENTEILENOFFENKUNDIGGUT

13. „Help; needed it is.”

14. Microservices
Monolithic Design
Microservice Design
Surviving Microservice Design

15. Kind of Definition
#WISSENTEILENOFFENKUNDIGGUT

16. „In short, the microservice architectural style is an
approach to developing a single application
as a suite of small services, each running in its
own process and communicating with lightweight
mechanisms, often an HTTP resource API.”
Martin Fowler (thoughtworks)

17. „As well as the fact that services are
independently deployable and scalable, each
service also provides a firm module boundary,
even allowing for different services to be written in
different programming languages. They can
also be managed by different teams.”
Martin Fowler (thoughtworks)

18. Microservice Design
Charakteristika
Microservices
Monolith are you kidding?
#WISSENTEILENOFFENKUNDIGGUT

19. Charakteristika
Microservice Design
Conway’s Law
#WISSENTEILENOFFENKUNDIGGUT

20. Charakteristika
„Any organization that designs
a system (defined broadly) will
produce a design whose structure
is a copy of the organization's
communication structure.“
Conway’s Law (1967)
Microservice Design
#WISSENTEILENOFFENKUNDIGGUT

21. Microservice Design
Charakteristikafree choice of language
free choice of DB
business driven teams
„DevOps“
#WISSENTEILENOFFENKUNDIGGUT

22. ‣ Maintainability
‣ Freedom of Evolution
‣ Replaceability
‣ Scalability
‣ Reliability & Resilience
‣ Fault Tolerance
‣ „Time to Market“
Microservice Design
Sounds great, doesn’t it!
#WISSENTEILENOFFENKUNDIGGUT

23. Microservices
Monolithic Design
Service Design
Surviving Service Design

24. Charakteristika
Surviving Service Design Microservices?
#WISSENTEILENOFFENKUNDIGGUT

25. Charakteristika
Surviving Service Design
#WISSENTEILENOFFENKUNDIGGUT

26. Charakteristika
Surviving Service Design
„For most software
projects, the primary
focus should be on
the domain and
domain logic.“
Eric Evans, 2004
#WISSENTEILENOFFENKUNDIGGUT

27. Charakteristika
Surviving Service Design
„Complex domain
design should be
based on a model.“
Eric Evans, 2004
Abstraction of
the domain!
#WISSENTEILENOFFENKUNDIGGUT

28. Surviving Service Design
So, what is your
Domain Model?
#WISSENTEILENOFFENKUNDIGGUT

29. Surviving Service Design
Domain Model
‣ Derive Objects (names)
from shared language
‣ Evolve Model with the help
of all participants
‣ BTW: Changes in language
lead to changes in model
#WISSENTEILENOFFENKUNDIGGUT

30. Surviving Service Design
One model to
rule them all.
#WISSENTEILENOFFENKUNDIGGUT

31. Surviving Service Design
Customer
ShoppingCart
Product
Kind of BIG,
isn’t it?
#WISSENTEILENOFFENKUNDIGGUT

32. „A Unit, that can be
handled in all aspects
by a small Team,
a.k.a. two Pizza Team”
Oliver Wegner (OTTO)

33. Surviving Service Design
Customer
ShoppingCart
Product
How to split?
#WISSENTEILENOFFENKUNDIGGUT

34. Surviving Service Design
Customer
ShoppingCart
Product
The challenge:
‣ Split model into smaller parts
without lost of DDD benefits
Possible conflicts:
‣ „different“ models
‣ „different“ understanding
#WISSENTEILENOFFENKUNDIGGUT

35. Surviving Service Design
Customer
ShoppingCart
Product
Split strategy:
„Domain
objects“
#WISSENTEILENOFFENKUNDIGGUT

36. „If every Service has to be
updated at the same time, it’s
not loosely coupled!”
by Adrian Cockcroft (ehemals Netflix)

37. „If you have to know too much about
the surrounding services you don’t
have a bounded context!”
by Adrian Cockcroft (ehemals Netflix)

38. Split strategy:
„Domain
objects“
Surviving Service Design
Customer
ShoppingCart
Product
#WISSENTEILENOFFENKUNDIGGUT

39. Surviving Service Design
Split strategy:
„Bounded
Context“
#WISSENTEILENOFFENKUNDIGGUT

40. Charakteristika
Surviving Service Design
Bounded Context, but how?
‣ clear borders
‣ business processes
‣ avoid inconsistencies
‣ e.g. check out
‣ e.g. present product
‣ e.g. „my“ recommendations
#WISSENTEILENOFFENKUNDIGGUT

41. Charakteristika
Surviving Service Design Dependencies?
Know your Neighbors!
#WISSENTEILENOFFENKUNDIGGUT

42. Surviving Service Design Context Map
Model still
consistent?
Data Owner?
Data still
consistent?
#WISSENTEILENOFFENKUNDIGGUT

43. „Starbucks does not use
Two-Phase Commit“
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

44. Surviving Service Design Shared Kernel
Mine? Yours?
#WISSENTEILENOFFENKUNDIGGUT

45. Surviving Service Design Shared Kernel
Versioning?
#WISSENTEILENOFFENKUNDIGGUT

46. „Be conservative in what you do,
be liberal in what you expect.“
Postel’s Law (a.k.a. robustness principle)
Surviving Service Design Versioning?
#WISSENTEILENOFFENKUNDIGGUT

47. Surviving Service Design Shared Kernel
Me, too!
And me, too!I need this!
#WISSENTEILENOFFENKUNDIGGUT

48. Surviving Service Design
Customer
ShoppingCart
Product
Core Domain
#WISSENTEILENOFFENKUNDIGGUT

49. Surviving Service Design Evolution?
#WISSENTEILENOFFENKUNDIGGUT

50. Charakteristika
Surviving Service Design
http://techblog.net.lix.com/2013/01/announcing-ribbon-tying-net.lix-mid.html
#WISSENTEILENOFFENKUNDIGGUT

51. Charakteristika„A Microservice
never walks alone!“
me, myself and I (2015)
Surviving Service Design
#WISSENTEILENOFFENKUNDIGGUT

52. Surviving Service Design
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
keep model unified by
Context Map
assess/overview
relationships with
Shared
Kernel
Overlap allied contexts through
Customer
Supplier
Teamsrelate allied contexts as
Conformist
overlap unilaterally as
Open Host
Service
support multiple
clients through
Published
Language
formalize as
Separate
Ways
free teams to go
Anticorruption
Layer
translate and insulate
unilaterally with
#WISSENTEILENOFFENKUNDIGGUT

53. Surviving Service Design
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
keep model unified by
Context Map
assess/overview
relationships with
Shared
Kernel
Overlap allied contexts through
Customer
Supplier
Teamsrelate allied contexts as
Conformist
overlap unilaterally as
Open Host
Service
support multiple
clients through
Published
Language
formalize as
Separate
Ways
free teams to go
Anticorruption
Layer
translate and insulate
unilaterally with
#WISSENTEILENOFFENKUNDIGGUT

54. Surviving Service Design
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
keep model unified by
Context Map
assess/overview
relationships with
Shared
Kernel
Overlap allied contexts through
Customer
Supplier
Teamsrelate allied contexts as
Conformist
overlap unilaterally as
Open Host
Service
support multiple
clients through
Published
Language
formalize as
Separate
Ways
free teams to go
Anticorruption
Layer
translate and insulate
unilaterally with
#WISSENTEILENOFFENKUNDIGGUT

55. Charakteristika
Surviving Service Design Microservices?
#WISSENTEILENOFFENKUNDIGGUT

56. Surviving Service Design
Search
History
Recommendations
User Management
Shopping Cart
Check out!
#WISSENTEILENOFFENKUNDIGGUT

57. Surviving Service Design
Product
User Management
Shopping Cart
History
Recommendations
Product presentation!
#WISSENTEILENOFFENKUNDIGGUT

58. „Size does matter" by Lars Röwekamp (open knowledge GmbH)
Surviving Service Design
Shopping Cart
History
Shipping
User Management
Customer Self Care!

59. Size does(n’t) matter
A personal point of View

60. My point of view
‣ „Use a shared common Language“
‣ „Know your Domain Model“
‣ „Know your Bounded Contexts“
‣ „Know your Neighbors“
‣ „Think (also) in Processes not only in Objects“
‣ „Be a tolerant Reader and a strict Supplier“
‣ BTW: „Talking to each other is still allowed!“
#WISSENTEILENOFFENKUNDIGGUT

61. Charakteristika
? ? ?
#WISSENTEILENOFFENKUNDIGGUT

62. Charakteristika
#WISSENTEILENOFFENKUNDIGGUT
Picture Credits …
‣ #1: iStock.com / Andrew Rich (000029536120)
‣ #3: photo © Daniel Steger for openphoto.net
‣ #10: The Art of Scalability / theartofscalability.com
‣ #13: iStock.com / jpgfactory (000059091620)
‣ #15: iStock.com / VisualField (3096596)
‣ #16: Wikimedia / Webysther 20150414193208
‣ #25: iStock.com / PeopleImages (62387488)
‣ #26: dddcommunity.org/uncategorized/about_the_cover
‣ #32: twitter.com/olliwegner
‣ #36: aws.amazon.com/de/heroes/usa/adrian-cockcroft/
‣ #44: pixabay.com
‣ #51: techblog.netflix.com/2013/01/announcing-ribbon-tying-netflix-mid.html