This document discusses applying domain-driven design patterns to serverless architecture. It begins by introducing the speaker and their background. It then provides an overview of serverless architecture and some of its benefits. The document goes on to discuss challenges that can arise with serverless applications as they grow in complexity, and suggests that organizing principles like domain-driven design patterns are needed. It proceeds to cover domain-driven design concepts like bounded contexts, aggregates, repositories, and CQRS, and provides examples of how they could be applied to serverless architecture. It concludes by discussing some interim conclusions, including that serverless is a new paradigm that requires principles to tame complexity, and that domain-driven design offers useful patterns for this purpose.

1. Shaping Serverless
Architecture with
Domain-Driven Design
Patterns
Asher Sterkin
asher.sterkin@gmail.com
PyWeb IL Meetup
03/05/2018, Google Campus

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: No Lambda
mysite.com
mySiteData
table instance
crud
bucket instance
Evaluation?
address reference
MySite_Users
MySite_Identies
get
AWS Cognito
User Pool
AWS Cognito
Identity Pool

15. Front-end Service
mysite.com
mySiteData
crud
Evaluation?
address reference
MySite_Users
MySite_Identies
get
mySiteRequestHandler
running instance(s)
invoke

16. Lambda Python3 “Hello World”
import json
print('Loading function')
def lambda_handler(event, context):
#print("Received event: " + json.dumps(event, indent=2))
print("value1 = " + event['key1'])
print("value2 = " + event['key2'])
print("value3 = " + event['key3'])
return event['key1'] # Echo back the first key value
#raise Exception('Something went wrong')

17. Front-end Service + API Gateway
mysite.com
mySiteData
crud
Evaluation?
address reference
MySite_Users
MySite_Identies
get
mySiteRequestHandler
invoke
api.mysite.com
/
API Gateway instance
API resource

18. 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?mysite.iot.com mySiteThermostatFrontendService

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

20. 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?

21. Bounded Context Services
DomainServiceA_DataDomainServiceA
DomainServiceB DomainServiceB_Data
crud
crud
Contains sensitive data!
Copy of publicly available data
Evaluation?
mySiteWebFrontendService

22. Bounded Context Services + Context Map
DomainServiceA_DataDomainServiceA
DomainServiceB DomainServiceB_Data
crud
crud
Evaluation?
mySiteWebFrontendService
DomainServiceB_DataStreams
DomainServiceB_EventHandler
trigger
put

23. 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?

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

25. 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?

26. CQRS
DomainServiceA_
AggregateX_StateData
DomainServiceA
_AggregateX_CommandHandler
DomainServiceA
_AggregateY_CommandHandler DomainServiceA_
AggregateY_StateData
get/put/delete
get/put/delete
Evaluation?
mySiteWebFrontendService
DomainServiceA_
View
DomainServiceA
_ViewBuilder
queries put/delete
get
get
commands
commands

27. 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
● Support for WebSockets (abusing IoT Gateway)
● Integration with AppSync (GraphQL)
● IoT Scalability
● Integration with specialized AWS services (e.g. AWS Comprehend)
● Custom Machine Learning in Event/Command Handlers
● Integration with Blockchain

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

29. “Consensus is poisonous
for innovation”
D. Snowden