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

How to start with DDD when you have a Monolith

How to start with DDD when you have a Monolith

Foundations on why and what do you need to start migrating to a DDD architecture

Ac38eb7117f177d961362cfe1387341b?s=128

Javiera Laso

June 22, 2022
Tweet

Other Decks in Technology

Transcript

  1. How to start with DDD when you have a Monolith

    Javiera Laso /jlasoc javujavichi
  2. Architecting applications is hard

  3. Conway’s Law Any organization that designs a system will inevitably

    produce a design whose structure is a copy of the organization’s structure (Melvin Conway-1968). E-COMMERCE BACKEND TEAM INFRA / DB TEAM FRONTEND TEAM javujavichi
  4. • Layered architecture • Modular architecture • MicroKernel Monoliths •

    Microservices • Service oriented architecture • Event oriented architecture Distributed EVENT ORIENTED MICROSERVICES BY LAYERS Our Goal Architecture MODULAR MONOLITH javujavichi
  5. What is a monolithic application? MODULAR MONOLITH BIG BALL OF

    MUD javujavichi
  6. Tech Debt Hard to deploy Legacy systems Can’t escalate BIG

    BALL OF MUD CI/CD process not implemented No boundaries in the services Hard to monitor No tests What do we have javujavichi
  7. Let’s start with DDD

  8. 1. Align Business model and user needs 2. Discover The

    domain visually & collaboratively 3. Decompose The domain into sub-domains 4. Connect Sub-domains to form a loosely coupled architecture 5. Strategize Business differentiating core-domains 6. Organize Teams around bounded contexts 7. Define Roles & responsibilities for bounded contexts 8. Code Your bounded context with tactical patterns DDD is continuous, and iterative Source: https://virtualddd.com/learning-ddd/ddd-crew-starter-modelling#the-process Domain driven design process javujavichi
  9. 1. Align Business model and user needs 2. Discover The

    domain visually & collaboratively 3. Decompose The domain into sub-domains 4. Connect Sub-domains to form a loosely coupled architecture 5. Strategize Business differentiating core-domains 6. Organize Teams around bounded contexts 7. Define Roles & responsibilities for bounded contexts 8. Code Your bounded context with tactical patterns DDD is continuous, and iterative Source: https://virtualddd.com/learning-ddd/ddd-crew-starter-modelling#the-process Domain driven design process javujavichi
  10. 1. Align Business model and user needs 2. Discover The

    domain visually & collaboratively 3. Decompose The domain into sub-domains 4. Connect Sub-domains to form a loosely coupled architecture 5. Strategize Business differentiating core-domains 6. Organize Teams around bounded contexts 7. Define Roles & responsibilities for bounded contexts 8. Code Your bounded context with tactical patterns DDD is continuous, and iterative Source: https://virtualddd.com/learning-ddd/ddd-crew-starter-modelling#the-process Domain driven design process javujavichi
  11. 1. Align Business model and user needs 2. Discover The

    domain visually & collaboratively 3. Decompose The domain into sub-domains 4. Connect Sub-domains to form a loosely coupled architecture 5. Strategize Business differentiating core-domains 6. Organize Teams around bounded contexts 7. Define Roles & responsibilities for bounded contexts 8. Code Your bounded context with tactical patterns DDD is continuous, and iterative Source: https://virtualddd.com/learning-ddd/ddd-crew-starter-modelling#the-process Domain driven design process javujavichi
  12. 1. Align Business model and user needs 2. Discover The

    domain visually & collaboratively 3. Decompose The domain into sub-domains 4. Connect Sub-domains to form a loosely coupled architecture 5. Strategize Business differentiating core-domains 6. Organize Teams around bounded contexts 7. Define Roles & responsibilities for bounded contexts 8. Code Your bounded context with tactical patterns DDD is continuous, and iterative Source: https://virtualddd.com/learning-ddd/ddd-crew-starter-modelling#the-process Domain driven design process javujavichi
  13. 13 SHOPPING CART PRODUCT CATALOG SHIPPING INVENTORY ORDERS INVOICE PAYMENT

    E-COMMERCE Bounded Context A Bounded Context is a delimited space where a business element has a perfectly defined meaning. javujavichi
  14. 14 Shipping context Inventory context Delivery Delivery estimate Shipping price

    E-COMMERCE Product Store Product Warehouse Customer Customer More Bounded Contexts, example javujavichi
  15. Payments gateway Provider/ Processor Gateway & messages SMTP service In

    dutch, please? Do not focus on technical details… Product payment The payment was processed correctly? Send the voucher to the customer’s email Now is clear to me ! Developers Domain experts …speak in business terms yes Payment order Domain Experts Common language between business and developers Developers javujavichi
  16. 16 The flow of events in the organization is discussed

    and that flow is modeled in an easy-to-understand way. It provides structure to the business flows that arise, but the real value is the conversations involved. You can build a software system from the models or simply use the knowledge gained from the discussions to better understand and refine business processes. Event Storming Credit card data entry Sent the credit card data Payment processing Payment gateway javujavichi
  17. What does the app do? javujavichi

  18. Applying in my monolith

  19. Migration patterns cheat sheet no Can you change your existing

    solution? Do you have a big ball of mud? In-place refactor Is the solution well structured? Modular Monolith Is business on board? Is domain functionality well understood? Are key personnel trained? Do you have strong intrapreneurs? Strangler Fig yes yes yes yes no no no no yes no yes Don’t change yes
  20. Migration patterns cheat sheet no Can you change your existing

    solution? Do you have a big ball of mud? In-place refactor Is the solution well structured? Modular Monolith Is business on board? Is domain functionality well understood? Are key personnel trained? Do you have strong intrapreneurs? Strangler Fig yes yes yes yes no no no no yes no yes Don’t change yes
  21. Migration patterns cheat sheet no Can you change your existing

    solution? Do you have a big ball of mud? In-place refactor Is the solution well structured? Modular Monolith Is business on board? Is domain functionality well understood? Are key personnel trained? Do you have strong intrapreneurs? Strangler Fig yes yes yes yes no no no no yes no yes Don’t change yes
  22. Plan Code Validate Pre-Deploy Tests Package Deploy Post-Deploy Tests Release

    Monitor Trunk-based Development Code Style Unit Testing Immutable Artifacts Ephemeral Environment Provisioning Automated Integration Testing Backwards Compatibility Testing Reporting & Dashboards Lightweight Architecture Governance IDE Integration SAST Contract Testing Image Scanning Toggle Configuration Automated Functional Testing Production Verification Testing Budget Management Developer Experience Local Dev Environments Static Code Analysis Architecture Fitness Functions Artifact Versioning Application Configuration Automated Performance Testing Sign-offs Metrics Refactoring Software Composition Analysis Standalone Component Testing Secrets Configuration Manual Exploratory Testing RASP Templates & Quickstarts Automated Code Reviews Mutation Testing Service Virtualization Chaos Testing Hotfix Pair Programming API Documentation Tests Test Data Management Automated Compliance Testing Disaster Recovery Test-Driven Design Schema Migrations Zero Downtime Deployments Developer Onboarding Incident Management DAST Structured Logging Zero Impact Deployments Distributed Tracing Micro Benchmarking Lightweight Domain Modeling Release Notes Synthetic Monitoring Synthetic Monitoring IAST Threat Modeling Automated Rollbacks Pre-commit Hooks Use the VSM for guidance Source: Premanand C. (On migration patterns talk)
  23. Plan Code Validate Pre-Deploy Tests Package Deploy Post-Deploy Tests Release

    Monitor Trunk-based Development Code Style Unit Testing Immutable Artifacts Ephemeral Environment Provisioning Automated Integration Testing Backwards Compatibility Testing Reporting & Dashboards Lightweight Architecture Governance IDE Integration SAST Contract Testing Image Scanning Toggle Configuration Automated Functional Testing Production Verification Testing Budget Management Developer Experience Local Dev Environments Static Code Analysis Architecture Fitness Functions Artifact Versioning Application Configuration Automated Performance Testing Sign-offs Metrics Refactoring Software Composition Analysis Standalone Component Testing Secrets Configuration Manual Exploratory Testing RASP Templates & Quickstarts Automated Code Reviews Mutation Testing Service Virtualization Chaos Testing Hotfix Pair Programming API Documentation Tests Test Data Management Automated Compliance Testing Disaster Recovery Test-Driven Design Schema Migrations Zero Downtime Deployments Developer Onboarding Incident Management DAST Structured Logging Zero Impact Deployments Distributed Tracing Micro Benchmarking Lightweight Domain Modeling Release Notes Synthetic Monitoring Synthetic Monitoring IAST Threat Modeling Automated Rollbacks Pre-commit Hooks Use the VSM for guidance Source: Premanand C. (On migration patterns talk)
  24. Plan Package Deploy Post-Deploy Tests Release Monitor Immutable Artifacts Ephemeral

    Environment Provisioning Automated Integration Testing Backwards Compatibility Testing Reporting & Dashboards Lightweight Architecture Governance Image Scanning Toggle Configuration Automated Functional Testing Production Verification Testing Budget Management Developer Experience Artifact Versioning Application Configuration Automated Performance Testing Sign-offs Metrics Secrets Configuration Manual Exploratory Testing RASP Service Virtualization Chaos Testing Hotfix Test Data Management Automated Compliance Testing Disaster Recovery Zero Downtime Deployments Incident Management DAST Zero Impact Deployments Distributed Tracing Lightweight Domain Modeling Release Notes Synthetic Monitoring Synthetic Monitoring IAST Threat Modeling Automated Rollbacks Use the VSM for guidance Code Trunk-based Development IDE Integration Local Dev Environments Refactoring Templates & Quickstarts Pair Programming Test-Driven Design Developer Onboarding Structured Logging Validate Code Style SAST Static Code Analysis Software Composition Analysis Automated Code Reviews Pre-commit Hooks Pre-Deploy Tests Unit Testing Contract Testing Architecture Fitness Functions Standalone Component Testing Mutation Testing API Documentation Tests Schema Migrations Micro Benchmarking Source: Premanand C. (On migration patterns talk)
  25. Plan Lightweight Architecture Governance Developer Experience Lightweight Domain Modeling Threat

    Modeling Use the VSM for guidance Code Trunk-based Development IDE Integration Local Dev Environments Refactoring Templates & Quickstarts Pair Programming Test-Driven Design Developer Onboarding Structured Logging Validate Code Style SAST Static Code Analysis Software Composition Analysis Automated Code Reviews Pre-commit Hooks Pre-Deploy Tests Unit Testing Contract Testing Architecture Fitness Functions Standalone Component Testing Mutation Testing API Documentation Tests Schema Migrations Micro Benchmarking Package Immutable Artifacts Image Scanning Artifact Versioning Deploy Ephemeral Environment Provisioning Toggle Configuration Application Configuration Secrets Configuration Service Virtualization Test Data Management Zero Downtime Deployments Zero Impact Deployments Post-Deploy Tests Automated Integration Testing Automated Functional Testing Automated Performance Testing Manual Exploratory Testing Chaos Testing Automated Compliance Testing DAST Synthetic Monitoring IAST Release Backwards Compatibility Testing Production Verification Testing Sign-offs RASP Hotfix Disaster Recovery Release Notes Automated Rollbacks Monitor Reporting & Dashboards Budget Management Metrics Incident Management Distributed Tracing Synthetic Monitoring
  26. Building Evolutionary Architecture Neal Ford, Rebecca Parsons & Patrick Kua

    Refactoring Martin Fowler & Ken Beck Monolith to Microservices Sam Newman Refactoring resources javujavichi
  27. Maintain architecture over time

  28. 28 javujavichi 28 C4 architecture diagrams are models that help

    explain applications and their systems from the general to the particular. This means that we can explain a system in 5 minutes, in 1 hour or in 5 hours. The 4 phases of the model are: system context, container diagram, component diagram, and code. https://c4model.com/ https://structurizr.com/ Molecular structure of natural rubber Visualize your Architecture (C4 diagrams)
  29. Test your architecture

  30. Architecture Decision Record (ADR) • Avoid dependency at cycle level.

    • Prevent the architecture definition from drifting over time. • Set architecture guidelines in the team • Automated tests with technical agreements at team level Goals
  31. Summarize

  32. Software Domain model Domain Codes Is part of represents Developers

    Domain experts (Business) Validates and help Source: https://fraktalio.com/ddd Talks and understand What is DDD? javujavichi
  33. 33 PAYMENTS TEAM INVENTORY TEAM SHIPPING TEAM ORDERS TEAM E-COMMERCE

    Build your teams in a way that reflects the architecture you want. Inverse Conway Manoeuvre javujavichi
  34. A full width image with text on top Adapt to

    change
  35. Technical business view

  36. Thank you /jlasoc javujavichi Feedback & Questions

  37. How to start with DDD when you have a Monolith

    Javiera Laso /jlasoc javujavichi
  38. Apendix

  39. 39 DB E-Commerce Inventory Event bus Shipping Payment class class

    Inventory class class Catalog class class Shipping class class Orders event Modular monolith javujavichi