Shaping serverless architecture with domain driven design patterns
8 likes3,055 views
This document discusses using Domain-Driven Design (DDD) patterns to structure serverless applications. It introduces DDD concepts like bounded contexts, aggregates, repositories, and CQRS. Bounded contexts separate domains into cohesive models that are loosely coupled. Aggregates define transactional boundaries and ensure data integrity. Repositories provide storage and retrieval of aggregates. CQRS separates commands and queries using different data models. Applying these DDD patterns can help organize serverless applications as they grow in complexity.
Shaping serverless architecture with domain driven design patterns
- 1. Shaping Serverless Architecture with Domain-Driven Design Patterns Asher Sterkin [email protected] AWS Users Group IL Meetup 02/06/2018, Tlv Partners
- 2. About Myself ● Software technologist/architect ● Former VP Technology @ NDS and Distinguished Engineer @ Cisco ● Currently CTO @ IRKI ● C-level mentoring on software strategy ● Cross-discipline approach (connecting the dots): ○ (Strategic) Domain-Driven Design ○ Serverless Architecture ○ Cynefin ○ Wardley Maps ○ Lean Startup ○ Promise Theory ○ ...
- 3. What is Serverless Architecture? ● No server management (pure on-demand computing) ● Flexible scaling (automatic or throttled) ● Highly available (AWS services are always on) ● Two flavors: ○ AWS Lambda - no pay for idle (ideal for spiky, unpredictable workloads) ○ AWS Fargate - log running containers (for stable latency and/or full control over run-time) ○ Could be combined ● More details ● Serverless computing is a tectonic shift in software industry ○ S. Wardley “Why the fuss about serverless?”
- 4. Serverless 3-tier Web Application Credit: Boaz Ziniman, “Serverless Use Cases with AWS Lambda” Data Store in Amazon DynamoDB Amazon S3 (static content) Amazon CloudFront Amazon API Gateway AWS Lambda (dynamic content) How many Lambda Functions and DynamoDB Tables are required to implement this?
- 5. Why Bother? Just throw in as many Lambdas as you wish
- 6. It Grows Rather Quickly Yan Cui, “Yubl’s Road to Serverless Architecture”
- 7. Serverless The danger is to come up with
- 8. Need Some Organizing Principles
- 9. Serverless Application Structure Factors ● Scalability ● Resource Utilization ● Access Control ● Productivity ● See also
- 10. Detour Documenting AWS Serverless Architecture
- 11. AWS Icons are Hopelessly Inconsistent When to use this? And when this? And when that?
- 12. What Does this Mean? AWS Service? SAM Template? AWS Lambda Deployment? Running Instance? AWS Service? SAM Template? DynamoDB Schema? DynamoDB Table Deployment? DynamoDB Table Instance? SDK Function Call? Data Flow? Address Reference? Access Rights?
- 13. 4+1 View of Software Architecture Conceptual Physical Process View Deployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance Scalability Throughput System integrators System topology Delivery, installation communication System engineering Analysts/Designers Structure ... ... P. Krutchen, “Architectural Blueprints - The “4+1” View Model of Software Architecture
- 14. Let’s Do It Again mysite.com api.mysite.com mySiteData / mySiteRequestHandler API resource running instance(s) table instance invoke crud bucket instance Evaluation? address reference API Gateway instance address reference
- 15. Separate Application and Domain Services mysite.com api.mysite.com DomainService_Data / mySiteWebFrontendService smartPhone mySiteSmartPhoneFrontendService DomainService DDD Focus is Here crud Ref: Netflix API Server-side Rendering Evaluation?
- 16. Domain-Driven Design at a Glance Language Model Boundaries Nesting Today’s focus An introductory presentation could be found here. Look at the end for recommended materials.
- 17. Introducing Bounded Context ● Maintaining “one-size fits all” domain model is seldom practical ● Any non-trivial software system usually needs multiple models ○ Highly cohesive inside (Bounded Context) ○ Loosely coupled outside (Context Map) ○ Good candidates for Microservices (E. Evans, “DDD and Microservices: At Last, Some Boundaries!”) Bounded Context A Strong Semantic Consistency Insides Bounded Context B Strong Semantic Consistency Inside Loose Coupling Outside Context Map Examples?
- 18. Bounded Context Services DomainServiceA_DataDomainServiceA DomainServiceB DomainServiceB_Data crud crud Contains sensitive data! Copy of publicly available data Evaluation? mySiteWebFrontendService
- 19. Bounded Context Services + Context Map DomainServiceA_DataDomainServiceA DomainServiceB DomainServiceB_Data crud crud Evaluation? mySiteWebFrontendService DomainServiceB_DataStreams DomainServiceB_EventHandler trigger put
- 20. Introducing Aggregate and Repository Strong Transaction Consistency + Invariant <<Aggregate Root>> Entity Entity Value Value Eventual Transaction Consistency aggregate storage store/retrieve requests --> command/query requests --> update/query method call --> ● Data integrity boundaries ● Strong transactional consistency inside ● Eventual consistency outside ● Inner parts are accessible only via Aggregate Root ● Inside Aggregate some form of invariant is maintained ● Aggregates of the same type are stored within Repository Command/query Request Processor Aggregate Repository Aggregate Example?
- 21. Aggregate, Repository, Command/Query Handler DomainServiceA_ AggregateX_Data DomainServiceA _AggregateX DomainServiceA _AggregateY DomainServiceA_ AggregateY_Data crud crud Evaluation? mySiteWebFrontendService command/query requests DomainServiceA AggregateY_EventHandler
- 22. Introducing CQRS ● Stands for Command/Query Request Segregation ● Was first proposed by Greg Yung ● Based on Command-Query Separation advocated by Bertrand Meyer: ○ Each method should either return something and leave object state intact ○ Or change the object state and return nothing (declared void) ● Interesting Aggregates usually justify separate Command/Query interfaces and data models Query Model Aggregate A State Aggregate B State Command interface Query interface Example?
- 24. Not Covered Here ● Separate Functions per Method/Event (easy, but needs justification) ● Event Sourcing (less easy, needs justification) ● Computation Services (not hard) ● Distributed Transactions (Saga) ● Fine-grained integration with API Gateway ● Integration with AppSync (GraphQL) ● Integration with IoT(Gateway) ● Integration with specialized AWS services (e.g. AWS Comprehend) ● Custom Machine Learning in Event/Command Handlers ● Integration with Blockchain
- 25. Interim Conclusions ● Serverless Architecture is a new beast to tame: ○ Gojko Adzic, “Designing for the Serverless Age” ● “4+1 View” approach helps with removing clutter from diagrams ○ Could used for Lightweight Architecture Decision Records ● Domain-Driven Design suggests a set of useful organizing principles ● Different options are valid under different circumstances ● It’s mostly about price/performance optimization ● Objective validation criteria: ○ Organizational structure (E. Evans, “DDD and Microservices: At Last, Some Boundaries!”) ○ Consistency tolerance (E. Evans “Acknowledging CAP at the Root - in the Domain Model”) ○ Security guidelines ○ Scalability needs ○ SOLID architecture principles
- 26. “Consensus is poisonous for innovation” D. Snowden