A talk by Asher Sterkin at the AWS User Group Israel on the 6 Feb 2018

1. Shaping Serverless
Architecture with
Domain-Driven Design
Patterns
Asher Sterkin
asher.sterkin@gmail.com
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?

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

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