Domain driven design at the heart of your microservices landscape

How bounded contexts and other patterns help you deliver on microservices promises.

With microservices and serverless are the current hypes, there are big promises of scalability, replaceability, and flexibility. However, when you are knee deep in mud as an architect, (front-end) developer or tester, it’s not always easy to see how.

At recent clients, in CTO roles, Sander Hoogendoorn has helped create landscapes of small microservices, that deliver on the promises above, with architectures based on the patterns from domain driven design. Moreover, these landscapes also feature many micro-applications, which are based on domain driven design patterns, that also deliver on the promises of microservices.

During this talk, Sander Hoogendoorn, independent craftsman and chief architect for IoT idea company Quby, discusses the set of patterns such as resources, representations, repositories, entities, value objects and factories that helped build these services and applications in an evolutionary architectural style. Sander also discusses why every micro-application and microservices has its bounded context, and how this domain driven design pattern is essential for enabling these landscapes of small services, of course, using many real-life examples.

Transcript

1. Domain driven design at the heart of your microservices landscape How bounded contexts and other patterns help you deliver on the promises of microservices Sander Hoogendoorn | Quby | ditisagile.nl @aahoogendoorn | Microservices. Right for your software development? Next
2. Sander Hoogendoorn Freelance new-agile coach, trainer, programmer, speaker, author, traveler, dad Currently Chief Architect Quby Before CTO ANVA CTO Klaverblad Verzekeringen Global agile thoughtleader Capgemini sanderhoogendoorn.com aahoogendoorn aahoogendoorn sander@ditisagile.nl Next @aahoogendoorn | How microteams change the way we collaborate. Again.
3. Click here Monoliths Hard to deliver Harder to test Impossible to maintain But… @aahoogendoorn | Microservices. Right for your software development?
4. Click here Who doesn’t have a system that is too big and that should be broken up?
5. More …
6. Click here The current stack Tools Enterprise Architect, IntelliJ, WebStorm, CLion, Visual Studio Code, LucidChart, Tableau, Zeplin PowerBi, QtCreator, Crowdin, PostMan, Jira, Confluence, Office365, TestFairy Languages JavaScript Java, C, C++, HTML, CSS, Scala, UML, SQL, Python, JSON, XML, Bash, Groovy, Lua, PHP, BoxTalk Frameworks Qt, Spring, Spring Boot, Spring Cloud Contract, Spring fox Swagger, Pact JVM, Resilience4j Liquibase, Slf4j, cypress.io, React, Backbone.js, Knockout, Mockito, Cucumber, Behave, Gurkin, node.js Lombok, JUnit, Debezium, dockerize, Serverless, CPPUtest, CUtest, Babel, Apache Spark, Hive Hibernate, QMF, Akka (Toolkit), Gatling, Apache CXF, TestNG, RestAssured Infra GitLab, Mesos Marathon, Consul, Jenkins, Sysdig, Apigee, count.ly, Docker, Terraform, Artifactory, Logstash Zookeeper, Coreos, ActiveMQ, Drupal, PagerDuty, Swagger, HTTP/s, MQTT, OpenVPN, Apache Tomcat Undertow, Jetty, AWS EC2, Beanstalk, S3, Lambda, CloudWatch, CloudTrail, SQS, SNS, Step Functions API Gateway, VPC, CloudFormation, IoT, ELB, GuardDuty, IAM, KMS, S3 Glacier, Elasticache Other Selenium, Kibana, ElasticSearch, MySQL, Redis, DataBricks, iWelcome, WSO2, OKTA, Cordova, Kentico Slack, Runscope, Liferay, Google Authenticator, Git, SonarQube, JWT, Google Repo, npm, Maven, Make Cmake, SBT, SOAP, Roadmunk, Illustrator, Runners, PhoneGap, ESLint, Z-Wave, Zigbee, WSL
7. Monolitths… Years of adding feature after feature @aahoogendoorn | Microservices. Right for your software development?
8. Read more … Monoliths. Advantages One architecture Single technology stack Single code base Often maintained by many teams Product Account Order Customer Products Accounts Orders Customers
9. Read more … Monoliths. Disadvantages All parts are interconnected Many other systems are connected to your system Hard to change, hard to maintain Long time between releases Slow innovation Hard to add new technologies Doesn’t scale very well Product Account Order Customer Products Accounts Orders Customers
10. Where software development went wrong Monoliths. Why we like them, why we hate them @aahoogendoorn | Microservices. Right for your software development? Continue
14. The code doesn’t break when you build it. It falls apart fifteen years later
15. Click here Dependencies will kill you every time
16. Click here Microservices Architecture Right for your software development? @aahoogendoorn | Microservices. Right for your software development?
17. Beyond the hype?
18. Gartner hype cycle
19. Greenfield or brownfield?
20. Click here Right for your software development?
21. Enter microservices architecture The world of small components that do one thing only @aahoogendoorn | Microservices. Right for your software development? Continue
22. Click here 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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Martin Fowler Microservices architecture @aahoogendoorn | Microservices. Right for your software development?
23. Read more … Promises Products not projects Scalable Decentralized governance Replaceable parts High performance Technology independent Polyglot persistence Easy to build Easy to test Easier deployment than monoliths
24. Read more … But… What is a microservice exactly? How small is a microservice? Requirements in a microservice world Components or services Who owns a microservice? What technologies do you use? What protocols do you apply? How to define messages How to test microservices How to coordinate when business services run across components? How to build deployment pipelines? How does integration really work? Where do we put our containers? Serverless?
25. Click here From the trenches Microservices in real life @aahoogendoorn | Microservices. Right for your software development?
26. On-premises legacy
27. Ancient languages
28. Aging programmers
29. Click here For the things we have to learn before we can do them, we learn by doing them Aristotle @aahoogendoorn | Microservices. Right for your software development?
30. Click here So what did we learn? @aahoogendoorn | Microservices. Right for your software development?
31. Click here What we learned Set up your guiding principles @aahoogendoorn | Microservices. Right for your software development?
32. Read more … Guiding principles We build business processes We move towards a landscape of micro-apps and microservices Requirements are modeled in smart use cases Micro-apps implement a single elementary business process step Micro-apps and microservices all have their own bounded context
33. Read more … Guiding principles Micro-apps don’t own storage Micro-apps only talk to other micro-apps and microservices Microservices own their storage Microservices only talk to other microservices Communication uses a simple open protocol – JSON over REST We avoid transactions like the plague
34. Click here What we learned Model your landscape to discover the services @aahoogendoorn | Microservices. Right for your software development?
35. Different levels of granularity Fish Clam Purpose Product Feature Function Too low Cloud Kite Sea Cloud Kite Sea OTOPOP One place One time One person
36. Click here Smart use cases – micro-app OTOPOP
37. Smart use cases OTOPOP OTOPOP OTOPOP OTOPOP OTOPOP
38. Click here Smart use cases - microservices
39. Click here What we learned Optimize for small changes @aahoogendoorn | Microservices. Right for your software development?
40. Complex problems require continuous exploration
41. Monolithical speed of change Monolith 1.0 Monolith 2.0 Monolith 3.0 Q1 Q2 Q3
42. Dependencies will kill you
43. Microservice and micro-app speed of change Account 1.0 Product 1.0 Create Order 1.0 Manage Docs 1.0 Account 20 Account 3.0 Account 4.0 Product 2.0 Product 3.0 Product 4.0 Product 5.0 Product 6..0 Create Order 2.0 Create Order 3.0 Manage Docs 2.0 Manage Docs 3.0 Q1 Q2 Q3
44. Click here What we learned Apply an evolutionary architecture @aahoogendoorn | Microservices. Right for your software development?
45. Click here It is not the strongest of the architectures that survives, nor the most complex that survives. It is the one that is most adaptable to change. Charles Darwin @aahoogendoorn | Microservices. Right for your software development? Evolutionary architecture
46. Click here Service interface Process Domain Data / Services Outside world Resources Representations Use cases Flow Factories, Repositories Entities, Enums, Value objects Storage gateways Storage Relations Dossiers Intermediaries Storage Microservice
47. Click here Resources, representations Table gateways, Service gateways Use cases Repositories, Factories, Services Entities, Value objects, Enums A microservice architecture Domain Process Data/Services Service interface
48. Resource (traditional Java)
49. Resource (functional Java)
50. Click here User interface Process Domain Data / Services Outside world Pages, WebComponents Grids, Panels, Controls Use cases Flow Factories, Repositories Entities, Enums, Value objects Service gateways Services Micro-app
51. Click here Pages, grids, web components Table gateways, Service gateways Use cases Repositories, Factories, Services Entities, Value objects, Enums A micro-app architecture Domain Process Data/Services User interface
52. Page (Angular)
53. Use case (Typescript)
54. Repository (Typescript)
55. Gateway (Typescript)
56. Click here What we learned Building micro-apps as microservices @aahoogendoorn | Microservices. Right for your software development?
57. Click here 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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Martin Fowler Microservices Architecture @aahoogendoorn | Microservices. Right for your software development?
58. Product Order Customer Credit card Vendor A single application? Web ordering system
59. Click here Given sufficient time any group of programmers will decide to rewrite the code. Ron Lunde @aahoogendoorn | Microservices. Right for your software development? Lunde’s Law
60. Front end frameworks 2016
61. Front end frameworks 2017
62. Front end frameworks 2018
63. Click here Low availability of “resources” Extremely tight
64. What if we would build (micro)apps with similar characteristics as microservices? @aahoogendoorn | Microservices. Right for your software development?
65. Click here In short, the microservice architectural style is an approach to developing a suite of small apps, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These micro-apps are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these apps, which may be written in different programming languages and use different data storage technologies. Martin Fowler Micro-apps Architecture @aahoogendoorn | Microservices. Right for your software development?
66. Business process (at kite level) Select Product Select Product Show Cart Check out Cart Register Client Register CC Show Order Product Order Customer CC Vendor Apps, workers and microservices Validate CC Confirm Order (email)
67. Read more … Benefits A landscape of micro-apps Built around a single business capability Easy to build East to test Deploy individually Allows for frequent change Functional reuse Allows for front end tech to evolve
68. Click here What we learned Separate concerns with bounded contexts @aahoogendoorn | Microservices. Right for your software development?
69. Read more … SOLID Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
70. Click here Group together things that change together Separate things that change for different reason Bob Martin Single responsibility principle @aahoogendoorn | Microservices. Right for your software development?
71. Read more … Single Responsibility Principle Every “module” should have responsibility over a single part of the functionality provided by the software, That responsibility should be entirely encapsulated by that module All its services should be narrowly aligned with that responsibility
72. Read more … Domain driven design The paradigm of designing software based on models of the underlying domain The domain model helps the business and the developers to reason about the functionality A model needs to be unified – internally consistent without contradictions The bounded context is a central pattern in domain driven design
73. Click here When you model larger domains, it becomes progressively harder to create this single unified model Instead of creating a single unified model, you create several, all valid within their bounded context Eric Evans Bounded contexts @aahoogendoorn | Microservices. Right for your software development?
74. The single unified domain model Product Vendor Stock Order Client Delivery Payment
75. Bounded contexts Product Vendor Stock Order Client Delivery Payment Product
76. Click here What we learned Split contexts in aggregates @aahoogendoorn | Microservices. Right for your software development?
77. Click here An aggregate is a group of associated objects which are considered as one unit with regard to data changes. The aggregate is demarcated by a boundary which separates the objects inside from those outside. Eric Evans Aggregates @aahoogendoorn | Microservices. Right for your software development?
78. Click here Each aggregate has one root. The root is an entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, but an outside object can hold references only to the root object. If there are other entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. Eric Evans Aggregate roots @aahoogendoorn | Microservices. Right for your software development?
79. Click here Bounded contexts and aggregates Invoice Shop Procurement
80. Click here Invoice Shop Procurement Bounded contexts, aggregates and microservices
81. Click here Aggregate
82. Entity (TypeScript)
83. Click here Foster immutability. Changes come from use cases Resources, representations Table gateways, Service gateways Use cases Repositories, Factories, Services Entities, Value objects, Enums
84. Immutability using factory methods (TypeScript)
85. Click here What we learned Let services own their own data @aahoogendoorn | Microservices. Right for your software development?
86. Monolithic dependencies replicate in the database Product Account Order Customer Product Account Order Customer
87. Splitting the monolith does not kill dependencies Product Account Order Customer Product Account Order Customer
88. Microservices need to own their data Product Account Order Customer Product Order Account Customer
89. Polyglot persistence Product Account Order Customer Product Order Account Customer Document DB Relational DB OLAP CRM API
90. Click here What we learned Standardize your API’s @aahoogendoorn | Microservices. Right for your software development?
91. Click here Structuring your API’s api.my-org.com/org/organizations api. my-org. com /org/organizations/318 api. my-org. com /org/organizations/somebank api. my-org. com /org/organizations?name=somebank api. my-org. com /org/tenants api. my-org. com /org/tenants/318 api. my-org. com /org/vendors api. my-org. com /org/organizations?type=“tenant”
92. Read more … Resources and aggregates Microservices are responsible for their own aggregate Microservices delivers services on resources Resources represent the aggregate root Behavior is modeled in use cases There usually is single factory for the aggregate root Microservice is named after aggregate root my-org.com/country Aggregate root represented as resource my-org.com/country/countries Find aggregate instance through the aggregate root ID my-org.com/country/countries/38 Find aggregate instances through other properties my-org.com/country/countries?isocode=“GRC”
93. Click here HTTP Return Codes Cheat Sheet 1**. Hold on 2**. Here you go 3**. Go away 4**. You fucked up 5**. I fucked up
94. Click here What we learned Avoid (point-to-point) contracts @aahoogendoorn | Microservices. Right for your software development?
95. Click here Communcation breakdown Presentation Process Domain Services Outside world Pages Grids, Panels, Controls Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways Components Relations Dossiers Intermediaries Rates Accounts Service interface Process Domain Data / Services Outside world Resources Representations Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways Storage Relations Dossiers Intermediaries MongoDB Micro-app Microservice
96. Point-to-point contracts Login { id: 42, firstname: Sander, lastname: H, city: Utrecht } { id, firstname, lastname, city } Account { id, firstname, lastname, city }
97. Click here Be conservative in what you send, be liberal in what you accept Jon Postel Postel’s Law @aahoogendoorn | Microservices. Right for your software development?
98. Multiple consumers, same producer Account { id, firstname, lastname, city } Login { id, login, password } Manage user { id, firstname, lastname }
99. Click here Software entities (classes, modules, functions, microservices, JSON objects, API’s) should be open for extension, but closed for modification Bob Martin Open closed principle @aahoogendoorn | Microservices. Right for your software development?
100. Click here What we learned Interface defensive @aahoogendoorn | Microservices. Right for your software development?
101. Click here Interface defensively. Even if you do own the services you consume, still design your consumers to treat your services as if they were from elsewhere and vice versa Sander Hoogendoorn @aahoogendoorn | Microservices. Right for your software development? Hoogendoorn’s Law
102. Anti-corruption, adapters and factory methods Account { id, firstname, surname, lastname, city } Login { id, login, password } Manage user { id, firstname, lastname }
103. Factory methods (TypeScript)
104. Factory methods (TypeScript)
105. Dealing with breaking changes Customer v1 App1 App2 Customer v1 App1 App2 v2 Customer v1 App1 App2 v2 Customer App1 App2 v2
106. Click here In retrospective Some final thoughts @aahoogendoorn | Microservices. Right for your software development?
107. Complex problems require continuous exploration
108. Click here Monoliths versus microservices? MÖNÖLIT MICRØ
109. Microservices teams are multi-disciplinary Architect Domain expert UX Front-end Back-end Mobile QA Ops AWS
110. Never stop learning Continue @aahoogendoorn | Microservices. Right for your software development?
111. And never forget to have fun @aahoogendoorn | Microservices. Right for your software development? Next
112. Click here References and questions www.sanderhoogendoorn.com aahoogendoorn aahoogendoorn sander@ditisagile.nl quby.com/careers @aahoogendoorn | Microservices. Right for your software development? We are hiring! sanderhoogendoorn.com/decks-and-handouts