Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Domain driven design at the heart of your microservices landscape

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.

58c16f97d28ebca36bbf3efff76258ce?s=128

Sander Hoogendoorn

May 22, 2019
Tweet

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
  11. None
  12. None
  13. None
  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