Splitting a system into microservices is a challenging task. This talk shows how ideas like Bounded Context, migration scenarios and technical constraints can be used to build a microservice architecture. Held at WJAX 2016.

1. How to Split Your
System into
Microservices
Eberhard Wolff
@ewolff
Fellow

2. http://continuous-delivery-buch.de/

3. http://microservices-buch.de/ http://microservices-book.com/

4. http://microservices-book.com/primer.html
FREE!!!!

6. Microservices:
Definition
> No consistent definition
> Microservices are modules
> Independent deployment units
> E.g. Docker container
> Microservice owned by one team

7. Microservices: Definition
Server /
Container
Server /
Container
Micro
Service
Micro
Service

8. Microservices aim for
decoupling

9. Why is the Split so
Important?
> Microservices implement a part of the logic
> Allow isolated development of features
> …and independent teams
> If split is wrong, you won’t achieve goals.
> …and there is just more complexity.
> But there are even more goals!

10. Why Microservices?
Strong Modularization
Scaling Agile
Sustainable development
Replaceable Services
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Small teams develop and
deploy independently
Add services – not code
Small Services
Failure limited to single
Microservice

11. Why Microservices?
Scaling Agile
Sustainable development
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Organization
Deployment
Units
Technology

12. There are many
reasons for
microservices.

13. There are many
scenarios for
microservices.

14. Scenario and reason
influence the split.

15. Bounded Context

17. UBIQUITOUS
LANGUAGE
VALUE
OBJECT
ENTITY

18. Address
VALUE
OBJECT
ENTITYor

19. 529 pages

20. 529 pages
Part IV

21. 529 pages
Part IV
Chapter 14

22. A domain model
is only useful
in a BOUNDED CONTEXT.

23. There is no
universal data model
in a large system.

24. Address
for a customer
VALUE
OBJECT
ENTITYor

25. Address
for calculating the
drones’ routes
VALUE
OBJECT
ENTITYor

26. Microservice =
Bounded Context

27. Create some
Bounded
Contexts!
Sir, yes, sir!

31. Why would you build
a universal data
model if that is
neither possible nor
useful??

32. Bounded Context:
Challenge
> Not a way to design a great architecture
> …but consequence of good domain
architecture
> i.e. clearly separated domains will lead to
separated BOUNDED CONTEXTS
> …containing logic and data
> How can you find BOUNDED CONTEXTS?

33. Bounded Context:
Challenge
> Coarse-grained
> Ideal: implement a functionality in one unit
> Ideal: Independence
> Might have relationships
> …limiting independence

34. Divide by Use Cases
> Microservice should implement a use case
> …ideally without calling other microservices
> Divide use cases among microservices
> …then decide about the BOUNDED CONTEXT

35. BrowsingRegistration
Creating Microservices
User Registration Search Products
by Keywords
Browse Products
by Category
Checkout
Payment
Define ShipmentUpdate Profile
Basic customer
data
Preferences
Recommendations
Billing address
Payment
information
All these services have data about the customer!!

36. Bounded Context
Scaling Agile
Sustainable development
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Organization
Deployment
Units
Technology

37. What about other
scenarios??

38. Existing Architecture
Product Customer Warehouse
Product
Service
Customer
Service
Warehouse
Service
iOS Android PoS Web

39. Let’s create some
Bounded Contexts!

40. Existing Architecture
Product Customer Warehouse
Product
Service
Customer
Service
Warehouse
Service
iOS Android PoS Web
Browsing

41. Bounded Contexts
> Browsing distributed in many artifacts
> Change to Browsing might influence all of
them
> …or not
> BOUNDED CONTEXTS would be desirable

42. Migrate to Bounded Context
Product Customer Warehouse
Product
Service
Customer
Service
Warehouse
Service
iOS Android PoS Web
BrowsingBrowsing

43. Introducing
Bounded Contexts
> …would change the architecture completely
> …might be very hard
> …and risky
> Is it worth it?
> Is it even doable?
> Might also change the organization

44. Add services
Product Customer Warehouse
Product
Service
Customer
Service
Warehouse
Service
iOS Android PoS Web

45. Add services
Product Customer Warehouse
Product
Service
Customer
Service
Warehouse
Service
iOS Android PoS Web
News-
letter
Web

46. Add Service
> Might replace the old system stepwise
> Immediate benefits
> Low risk
> Major reason for microservices

47. Cut existing services
Product Customer Warehouse
Product
Service
Customer
Service
Warehouse
Service
iOS Android PoS Web

48. Existing Architecture
Scaling Agile
Sustainable development
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Organization
Deployment
Units
Technology

49. Existing Architecture
> ...has an impact on the target architecture
> What good is an architecture you cannot
migrate into?
> Might overrule everything else
> Even BOUNDED CONTEXT

50. BrowsingRegistration
External Systems
User Registration Search Products
by Keywords
Browse Products
by Category
Checkout
Payment
Define ShipmentUpdate Profile Browse Products
by Category
Payment
Provider
Logistic
Partner

51. BrowsingRegistration
External Systems
User Registration Search Products
by Keywords
Browse Products
by Category
Checkout
Update Profile Browse Products
by Category
Payment
Provider
Logistic
Partner
Payment Shipping

52. External Systems
> Limit integration for each external system to
one Microservice
> External system might belong to a domain
> …or BOUNDED CONTEXT
> ...or not
> Simplifies integration
> Easier to achieve robustness

53. External Systems
Scaling Agile
Sustainable development
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Organization
Deployment
Units
Technology

54. We expect a
lot more
registrations!

55. BrowsingRegistration
External Systems
User Registration Search Products
by Keywords
Browse Products
by Category
Checkout
Payment
Define ShipmentUpdate Profile Browse Products
by Category

56. BrowsingRegistration
External Systems
Search Products
by Keywords
Browse Products
by Category
Checkout
Payment
Define ShipmentBrowse Products
by Category
Regis-
tration
Update
Profile

57. Technical Reasons
> Independent scalability is just one technical
reason
> There are many more
> Might be OK to share database in this
scenario
> Might even split read and write

58. CQRS
> Command – Query Responsibility
Segregation
> Commands change data
> Query provide data
> Implement in separate microservices

59. Command
Queue
Command
Command
Command
Command
Handler
Query
Handler
Command
Store
Database Read Replica

60. Technical Reasons
Scaling Agile
Sustainable development
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Organization
Deployment
Units
Technology

61. Registration
Requirements
Browsing Checkout
Marketing Sales Fulfillment Finance

62. Requirements
> One microservice should implement one
stream of requirements
> Otherwise: coordinate priorities
> …and therefore less independence

63. Registration
Requirements
Browsing Payment
Marketing Sales FulfillmentFinance
Shipping

64. Requirements
Scaling Agile
Sustainable development
Continuous Delivery
Free choice of technology
Handle Legacy efficient
Independent Scaling
Robustness
Organization
Deployment
Units
Technology

65. Conclusion

66. Microservices
= Bounded Context

67. Split
Bounded
Context
Migration
External
Systems
Technical
Reasons
Require-
ments

68. EMail slideswjax2016@ewolff.com to get:
Slides
+ Microservices Primer
+ Sample Microservices Book
+ Sample of Continuous Delivery Book
Powered by Amazon Lambda & Microservices