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
   

   View Slide

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.
   

   View Slide

3. Click here
   Monoliths
   Hard to deliver
   Harder to test
   Impossible to maintain
   But…
   @aahoogendoorn | Microservices. Right for your software
   development?
   

   View Slide

4. Click here
   Who doesn’t have a system
   that is too big
   and that should be broken up?
   

   View Slide

5. More …
   

   View Slide

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
   

   View Slide

7. Monolitths… Years of adding feature after feature
   @aahoogendoorn | Microservices. Right for your software development?
   

   View Slide

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
   

   View Slide

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
   

   View Slide

10. Where software development went wrong
    Monoliths. Why we like them, why we hate them
    @aahoogendoorn | Microservices. Right for your software development?
    Continue
    

    View Slide

11. View Slide

12. View Slide

13. View Slide

14. The code doesn’t break when you build it. It falls apart fifteen years later
    

    View Slide

15. Click here
    Dependencies will kill you every time
    

    View Slide

16. Click here
    Microservices
    Architecture
    Right for
    your software
    development?
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

17. Beyond the hype?
    

    View Slide

18. Gartner hype cycle
    

    View Slide

19. Greenfield or brownfield?
    

    View Slide

20. Click here
    Right for your software development?
    

    View Slide

21. Enter microservices architecture
    The world of small components that do one thing only
    @aahoogendoorn | Microservices. Right for your software development?
    Continue
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

25. Click here
    From the trenches
    Microservices in real life
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

26. On-premises legacy
    

    View Slide

27. Ancient languages
    

    View Slide

28. Aging programmers
    

    View Slide

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?
    

    View Slide

30. Click here
    So what did
    we learn?
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

31. Click here
    What we learned
    Set up your
    guiding principles
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

34. Click here
    What we learned
    Model your landscape
    to discover the services
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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
    

    View Slide

36. Click here
    Smart use cases – micro-app
    OTOPOP
    

    View Slide

37. Smart use cases
    OTOPOP
    OTOPOP
    OTOPOP
    OTOPOP
    OTOPOP
    

    View Slide

38. Click here
    Smart use cases - microservices
    

    View Slide

39. Click here
    What we learned
    Optimize for
    small changes
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

40. Complex problems require continuous exploration
    

    View Slide

41. Monolithical speed of change
    Monolith
    1.0
    Monolith
    2.0
    Monolith
    3.0
    Q1 Q2 Q3
    

    View Slide

42. Dependencies will kill you
    

    View Slide

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
    

    View Slide

44. Click here
    What we learned
    Apply an
    evolutionary
    architecture
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

48. Resource (traditional Java)
    

    View Slide

49. Resource (functional Java)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

52. Page (Angular)
    

    View Slide

53. Use case (Typescript)
    

    View Slide

54. Repository (Typescript)
    

    View Slide

55. Gateway (Typescript)
    

    View Slide

56. Click here
    What we learned
    Building micro-apps
    as microservices
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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?
    

    View Slide

58. Product Order Customer Credit card Vendor
    A single application?
    Web ordering system
    

    View Slide

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
    

    View Slide

60. Front end frameworks 2016
    

    View Slide

61. Front end frameworks 2017
    

    View Slide

62. Front end frameworks 2018
    

    View Slide

63. Click here
    Low availability of “resources”
    Extremely tight
    

    View Slide

64. What if we would build (micro)apps with
    similar characteristics as microservices?
    @aahoogendoorn | Microservices. Right for your software development?
    

    View Slide

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?
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

68. Click here
    What we learned
    Separate concerns
    with bounded contexts
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

69. Read more …
    SOLID
    Single Responsibility Principle
    Open Closed Principle
    Liskov Substitution Principle
    Interface Segregation Principle
    Dependency Inversion Principle
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

74. The single unified domain model
    Product
    Vendor
    Stock
    Order
    Client
    Delivery
    Payment
    

    View Slide

75. Bounded contexts
    Product
    Vendor
    Stock
    Order
    Client
    Delivery
    Payment
    Product
    

    View Slide

76. Click here
    What we learned
    Split contexts
    in aggregates
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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?
    

    View Slide

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?
    

    View Slide

79. Click here
    Bounded contexts and aggregates
    Invoice
    Shop
    Procurement
    

    View Slide

80. Click here
    Invoice
    Shop
    Procurement
    Bounded contexts, aggregates and microservices
    

    View Slide

81. Click here
    Aggregate
    

    View Slide

82. Entity (TypeScript)
    

    View Slide

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
    

    View Slide

84. Immutability using factory methods (TypeScript)
    

    View Slide

85. Click here
    What we learned
    Let services
    own their own data
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

86. Monolithic dependencies replicate in the database
    Product Account
    Order Customer
    Product Account
    Order Customer
    

    View Slide

87. Splitting the monolith does not kill dependencies
    Product Account
    Order Customer
    Product Account
    Order Customer
    

    View Slide

88. Microservices need to own their data
    Product Account
    Order Customer
    Product Order Account Customer
    

    View Slide

89. Polyglot persistence
    Product Account
    Order Customer
    Product Order Account Customer
    Document DB Relational DB OLAP CRM API
    

    View Slide

90. Click here
    What we learned
    Standardize
    your API’s
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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”
    

    View Slide

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”
    

    View Slide

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
    

    View Slide

94. Click here
    What we learned
    Avoid (point-to-point)
    contracts
    @aahoogendoorn | Microservices. Right for your software
    development?
    

    View Slide

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
    

    View Slide

96. Point-to-point contracts
    Login
    {
    id: 42,
    firstname: Sander,
    lastname: H,
    city: Utrecht
    }
    {
    id,
    firstname,
    lastname,
    city
    }
    Account
    {
    id,
    firstname,
    lastname,
    city
    }
    

    View Slide

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?
    

    View Slide

98. Multiple consumers, same producer
    Account
    {
    id,
    firstname,
    lastname,
    city
    }
    Login
    {
    id,
    login,
    password
    }
    Manage user
    {
    id,
    firstname,
    lastname
    }
    

    View Slide

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?
    

    View Slide

100. Click here
     What we learned
     Interface defensive
     @aahoogendoorn | Microservices. Right for your software
     development?
     

     View Slide

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
     

     View Slide

102. Anti-corruption, adapters and factory methods
     Account
     {
     id,
     firstname,
     surname,
     lastname,
     city
     }
     Login
     {
     id,
     login,
     password
     }
     Manage user
     {
     id,
     firstname,
     lastname
     }
     

     View Slide

103. Factory methods (TypeScript)
     

     View Slide

104. Factory methods (TypeScript)
     

     View Slide

105. Dealing with breaking changes
     Customer
     v1
     App1 App2
     Customer
     v1
     App1 App2
     v2
     Customer
     v1
     App1 App2
     v2
     Customer
     App1 App2
     v2
     

     View Slide

106. Click here
     In retrospective
     Some final thoughts
     @aahoogendoorn | Microservices. Right for your software
     development?
     

     View Slide

107. Complex problems require continuous exploration
     

     View Slide

108. Click here
     Monoliths versus microservices?
     MÖNÖLIT MICRØ
     

     View Slide

109. Microservices teams are multi-disciplinary
     Architect
     Domain
     expert
     UX
     Front-end
     Back-end
     Mobile
     QA
     Ops
     AWS
     

     View Slide

110. Never stop learning
     Continue
     @aahoogendoorn | Microservices. Right for your software development?
     

     View Slide

111. And never forget to have fun
     @aahoogendoorn | Microservices. Right for your software development?
     Next
     

     View Slide

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
     

     View Slide