How to start with DDD when you have a Monolith Javiera Laso /jlasoc javujavichi

Architecting applications is hard

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

● 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

What is a monolithic application? MODULAR MONOLITH BIG BALL OF MUD javujavichi

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

Let’s start with DDD

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

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

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

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

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 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 Shipping context Inventory context Delivery Delivery estimate Shipping price E-COMMERCE Product Store Product Warehouse Customer Customer More Bounded Contexts, example javujavichi

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 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

What does the app do? javujavichi

Applying in my monolith

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

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

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

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)

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)

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)

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

Building Evolutionary Architecture Neal Ford, Rebecca Parsons & Patrick Kua Refactoring Martin Fowler & Ken Beck Monolith to Microservices Sam Newman Refactoring resources javujavichi

Maintain architecture over time

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)

Test your architecture

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

Summarize

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 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

A full width image with text on top Adapt to change

Technical business view

Thank you /jlasoc javujavichi Feedback & Questions

How to start with DDD when you have a Monolith Javiera Laso /jlasoc javujavichi

Apendix

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