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

2020-06-27 DDD Taiwan Community Microservices B...

2020-06-27 DDD Taiwan Community Microservices Bounded Context and everything in Between

This talk is redelivered from DDDDD @vladikk's session by Kim, Kao. The main concept is to figure out how to design microservices with more confidence to make decision. Also mentioned what's the essential concept on API, distributed events, and etc.

Kim Kao

June 27, 2020
Tweet

More Decks by Kim Kao

Other Decks in Programming

Transcript

  1. © 2020, Domain Driven Design Taiwan Community Kim Kao, Co-Organizer

    Domain Driven Design Taiwan Community 27 June, 2020 Microservices Bounded Context And everything in Between @YiKaiKao Kim Kao @Vladikk
  2. © 2020, Domain Driven Design Taiwan Community Kim, Kao (高翊凱)

    • A father of 2 • Love Softball / Baseball • Passionate facilitator • Domain Driven Design Taiwan Community Co-Organizer • Solutions Architect @AWS – Big Serverless Fan !!!
  3. © 2020, Domain Driven Design Taiwan Community 95% of the

    words are spent extolling the benefits of “modularity” and that little, if any, is said about how to achieve it Glenford J. Myers
  4. © 2020, Domain Driven Design Taiwan Community Product Marketing Strategy

    Creatives Campaigns Sales Agent Profits Optimization
  5. © 2020, Domain Driven Design Taiwan Community Conflicting models Different

    contexts Dividing the lamguage/model Bounded Context
  6. © 2020, Domain Driven Design Taiwan Community Bounded Contexts Marketing

    Sales Funnel Campaign Placement Landing Page Agency Insertion Order Lead Contact CDR Conversion Desk Campaign Proposition Message Lead
  7. © 2020, Domain Driven Design Taiwan Community Decomposition Strategy #1:

    Bounded Contexts Marketing Service Sales Service
  8. © 2020, Domain Driven Design Taiwan Community Marketing Sales Billing

    Creative Catalog Campaign Management Ads Optimization Identity & Access Contracts Telephony CRM Sales Optimization Commissions Desks Identity & Access
  9. © 2020, Domain Driven Design Taiwan Community Business Domain: Customer

    Acquisition Bounded Context: Marketing Bounded Context: Sales SubDomain: Creative Catalog SubDomain: Campaigns Mgt SubDomain: Ads Optimization SubDomain: Contracts Mgt SubDomain: CRM SubDomain: Sales Optimization SubDomain: Commissions SubDomain: Desk Mgt
  10. © 2020, Domain Driven Design Taiwan Community Decomposition Strategy #2:

    Subdomains Campaign Management service Content Catalog Service Desk Management Service CRM Service Users Service Billing Service
  11. © 2020, Domain Driven Design Taiwan Community Marketing Billing Creative

    Catalog Campaign Management Ads Optimization Identity & Access Contracts Campaign Management Campaign Placement Funnel Banner Website Asset Target Market Landing Page
  12. © 2020, Domain Driven Design Taiwan Community Decomposition Strategy #3:

    Entities Website Asset Target Market Broker Distribution Order
  13. © 2020, Domain Driven Design Taiwan Community Quick wrap -

    Decomposition Strategies Bounded Contexts Subdomains Business Entities and Processes
  14. © 2020, Domain Driven Design Taiwan Community Website Funnel Campaign

    Placement Bounded Contexts? Subdomains? Entities?
  15. © 2020, Domain Driven Design Taiwan Community Marketing Sales Landing

    Page Campaign Placement Agency Lead Funnel Contact CDR Conversion Proposition Desk Message Insertion Order Lead
  16. © 2020, Domain Driven Design Taiwan Community Marketing Sales Landing

    Page Campaign Placement Agency Lead Funnel Contact CRM Conversion Proposition Desk Message Insertion Order Lead
  17. © 2020, Domain Driven Design Taiwan Community Marketing Support Sales

    Lead Lead Identity & Access Campaign Mgt Optimization Contracts Desks Telephony Billing Creative Catalog CRM Commissions Optimization
  18. © 2020, Domain Driven Design Taiwan Community Bounded Contexts Decomposition

    #2 Bounded Contexts Decomposition #1 Bounded Contexts Decomposition #3
  19. © 2020, Domain Driven Design Taiwan Community Bounded Context Consistency

    boundary of the language / model Define the biggest valid monoliths Required decomposition boundary
  20. © 2020, Domain Driven Design Taiwan Community Service “A service

    is a unit of functionality exposed to the world” – Juval Lowy “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface” - OASIS
  21. © 2020, Domain Driven Design Taiwan Community Service Interface “Any

    mechanism for getting data in or out of the service” – Randy Shoup
  22. © 2020, Domain Driven Design Taiwan Community Service Interface Asynchronous:

    • Producing events • Consuming events Synchronous: • Request / Response • Bulk ETL
  23. © 2020, Domain Driven Design Taiwan Community Service Interface “Any

    mechanism for getting data in or out of the service” – Randy Shoup
  24. © 2020, Domain Driven Design Taiwan Community Microservice = Microinterface

    Reducing coupling between services Limits reasons for change Easier to understand Better fault isolation More autonomy between services
  25. © 2020, Domain Driven Design Taiwan Community Microservice & Databases

    Microservices should own its database No external access Access through Microservice’s API only Database = infinite interface!
  26. © 2020, Domain Driven Design Taiwan Community The threshold upon

    which a system can be decomposed into microservices is defined by the use cases of the system that the microservices are a part of.
  27. © 2020, Domain Driven Design Taiwan Community Cost Of Change

    Monolith Microservices Distributed Monolith
  28. © 2020, Domain Driven Design Taiwan Community Cost Of Change

    Big Ball of Mud Bounded Contexts Distributed Big Ball of Mud Microservices
  29. © 2020, Domain Driven Design Taiwan Community Website Funnel Campaign

    Placement Entities? Subdomains? Microservice candidate - dependens Resolve Global Complexity
  30. © 2020, Domain Driven Design Taiwan Community “Global complexity …

    the complexity of the overall structure of a program or system. i.e, the degree of association or interdependence Among the major pieces of a program” Glenford J. Myers - 1978 Composite / Structured Design
  31. © 2020, Domain Driven Design Taiwan Community When you design

    a system…, then if the features can be break into … loosely bound groups of relatively closely bound features, then that division is a good thing to be mad a part of the design. This is just good engineering. Tim Berners-Lee Principles of design, 1998
  32. © 2020, Domain Driven Design Taiwan Community Its is not

    only necessary to make sure your own system is designed to be made of modular parts. It is also necessary to realize that your own system… should always be designed to be a part of another larger system. Tim Berners-Lee Principles of design, 1998
  33. © 2020, Domain Driven Design Taiwan Community A major part

    of this paper will be concerned with the question of how good modularity can be achieved, that is, how modules can be chosen to as to minimize the connections between them. Barbara Liskov A design methodology for reliable software systems, 1972
  34. © 2020, Domain Driven Design Taiwan Community A microservice is

    a service with a micro interface. The threshold upon which a system can be decomposed Into microservices is defined by the use cases of the System that the microservices are a part of.
  35. © 2020, Domain Driven Design Taiwan Community Heuristic #1: Decompose

    to Bounded Contexts Do not implement conflicting models in the same service. Always decompose to Bounded Contexts.
  36. © 2020, Domain Driven Design Taiwan Community Heuristic #2: Don’t

    First Law of Distributed Object Design: “Don’t distribute your objects” Martin Fowler
  37. © 2020, Domain Driven Design Taiwan Community Generic Subdomains No

    competitive advantage Everybody is implementing in the same way Complex business logic Services : Billing, A&A, Telepony …
  38. © 2020, Domain Driven Design Taiwan Community Heuristic #3: Buy/Adopt

    Generic subdomains 3rd party product Your system Anti-Corruption Layer
  39. © 2020, Domain Driven Design Taiwan Community Core Subdomains Inventing

    something new Optimizing existing practices Competitive advantage Complex business logic Change often Services : Campaign, Ad Optimization, CRM, Sales, Commissions
  40. © 2020, Domain Driven Design Taiwan Community Heuristic #4: Core

    Subdomains – Don’t Rush Adhere to subdomain’s boundaries. Decompose further only when you acquire domain knowledge.
  41. © 2020, Domain Driven Design Taiwan Community Supporting Subdomains No

    competitive advantage Support the Core Subdomains Can’t be bought / adopted Simple bussiness logic Services : Creative Catalog, Contracts, Desks
  42. © 2020, Domain Driven Design Taiwan Community Heuristic #5: Supporting

    Subdomains - Safe Safe to decompose beyond the subdomain’s boundaries.
  43. © 2020, Domain Driven Design Taiwan Community Heuristic #6: Evaluate

    Consistency Requirements Method A Method B Conscurrency control? – Same service Service A
  44. © 2020, Domain Driven Design Taiwan Community Heuristic #6: Evaluate

    Consistency Requirements Conscurrency control? – Same service Method A Service A Method B Service B Sync Call
  45. © 2020, Domain Driven Design Taiwan Community Heuristic #6: Evaluate

    Consistency Requirements Eventual Consistency? – Two Services, async communication Method A Service A Method B Service B Async communication
  46. © 2020, Domain Driven Design Taiwan Community Heuristic #6: Evaluate

    Consistency Requirements Concurrency control? – Same Service Read last write? – Two services, sync communication Eventual consistency? – Two services, async communication
  47. © 2020, Domain Driven Design Taiwan Community Heuristic #7: Public

    / Private Events … … … … … … Event Type 3 Event Type 2 Event Type 1 Event Type 100 …
  48. © 2020, Domain Driven Design Taiwan Community Heuristic #7: Public

    / Private Events Service emailChanged phoneNumberChanged addressChanged contactDetailChanged Private event types (Implementation details) public event types (public interface)
  49. © 2020, Domain Driven Design Taiwan Community Heuristic #7: Public

    / Private Events Events? Domain Events State Change Events Private Public
  50. © 2020, Domain Driven Design Taiwan Community Heuristic #8: Make

    Events Explicit Service AgentAssignedToLead AgentAssignedToLead AgentAssignedToLead
  51. © 2020, Domain Driven Design Taiwan Community Heuristic #8: Make

    Events Explicit Service AgentAssignedToLead AgentAssignedToLead AgentUnassignedToLead
  52. © 2020, Domain Driven Design Taiwan Community Heuristic #9: Evaluate

    reasons for Change Method A Service A Method B Service B Sync Call
  53. © 2020, Domain Driven Design Taiwan Community Heuristic #9: Evaluate

    reasons for Change Same reasons for change? Same rate of change? Can be decoupled? Should be the same service?
  54. © 2020, Domain Driven Design Taiwan Community Wrap it up

    • A service is a unit of functionality exposed to the world through its public interface • A microservice is a service with micro interface • The “Micro-interface” is relative to the use cases of the system that the service is a part of
  55. © 2020, Domain Driven Design Taiwan Community Wrap it up

    • Heuristic #1: Always decompose to Bounded Contexts • Heuristis #2: Don’t go further, unless you have to • Heuristic #3: Buy/Adopt generic subdomains • Heuristic #4: Core subdomains – don’t rush • Heuristic #5: Supporting subdomains can be decomposed ear • Heuristic #6: Evaluate Consistency Requirements • Heuristic #7: Private / Public Events • Heuristic #8: Explicit Define Events • Heuristic #9: Evaluate Reasons for Change • Heuristic #10: Evaluate Services’ “Doors”
  56. © 2020, Domain Driven Design Taiwan Community Cost Of Change

    Big Ball of Mud Bounded Contexts Distributed Big Ball of Mud Microservices