Scenarios_and_Architecture_SkillsMatter_April_2022.pdf

@crichardson
Using scenarios to reinvigorate
your (microservice) architecture
Chris Richardson

Microservice architecture consulting and training
Founder of Eventuate.io

Founder of the original CloudFoundry.com

Author of POJOs in Action and Microservices Patterns

@crichardson

chris@chrisrichardson.net

http://adopt.microservices.io
Copyright © 2022. Chris Richardson Consulting, Inc. All rights reserved
^
views and

@crichardson
Presentation goal
How to create
minimal, yet
effective
architecture
documentation
Order Management
Consumer
Management
Credit Card Payments
Restaurant
Management
Accounting
Kitchen Management
Vague!
API Gateway
Import
DynamoDB
Kinesis Streams
Lambda Query
Technology
focussed
Disconnected from
functional requirements

@crichardson
About Chris

@crichardson
Discounts
35% discount

au35ric

$100 discount coupon

QVYVPXMY until June 6th

@crichardson
Agenda
The 4+1 view model of software architecture

Documenting the FTGO application

Beyond views

The goal of architecture is to
satisfy non-functional requirements
Nonfunctional
requirements
Development
Runtime
Scalability
Performance
Availability
…
Maintainability
Testability
Deployability
…
Often neglected

About software architecture
“The software architecture of a computing system is the
set of structures needed to reason about the system,
which comprise software elements, relations among
them, and properties of both.”

Documenting Software Architectures, Bass et al

De
fi
ningthe architecture of a new application

Learningthe architecture, e.g. new team member

Evaluatingthe architecture in order to improve it

Evolvingthe architecture to satisfy changed requirements

@crichardson
Architecture

=

(elements, relations, properties)

@crichardson
Architecture

=

Boxes and lines 😄

@crichardson
Architecture is multi-dimensional
• Structural

• Electrical

• Plumbing

• Mechanical

• …

@crichardson
View

=

(elements, relations, properties)
Architecture

=

4+1 view model of software
architecture
Logical

View
Process

View
Deployment

View
Implementation

View
Scenarios
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model

4+1 Logical view
Logical

View
Process

View
Deployment

View
Implementation

View
Scenarios
Elements: classes and packages

Relations: inheritance, associations, …

4+1 Implementation view
Logical

View
Process

View
Deployment

View
Implementation

View
Scenarios
Elements: modules and components

Relations: dependencies
Monolith

=

one component
Microservices

=

many components

4+1 Process view
Logical

View
Process

View
Deployment

View
Implementation

View
Scenarios
Elements: processes

Relations: IPC

4+1 Deployment view
Logical

View
Process

View
Deployment

View
Implementation

View
Scenarios
Elements: “machines”

Relations: networking

@crichardson
Different views describe different
aspects of the architecture
Logical

View
Process

View
Deployment

View
Implementation

View
Dev Ops
Modularity

Loose coupling
Availability

Scalability

+1 = 5th view = Scenarios
Logical

View
Process

View
Deployment

View
Implementation

View
Scenarios
Derived from use cases/stories

Animate the views
Elements from a
view

@crichardson
Views: more than just pretty
pictures
«Service»
Order Management «Service»
Consumer
Management
«Service»
«Service»
Restaurant
Management
«Service»
Accounting
«Service»
Kitchen Management
«Service»
Service
«Database»
Database
Uses API
Legend
Part-of
«Service»
API Gateway
«async»
«subscribes to»
«async»
«async»
«async»
«async»
«sync»
«sync»
«sync»
«sync»
«sync»
Diagram Description of elements and relations

@crichardson
Alternatives to the classic 4+1
views
There are other views, e.g.

Modern deployment technologies (Kubernetes, Serverless)
don’t
fi
t with process/deployment views

Hybrid views and scenarios that mix elements (e.g. services
and entities)

Git repository/Service/Deployment pipeline view

…

Goal is communicate => use the views that are useful

@crichardson
Documenting the FTGO application
«Service»
Consumer
Management
«Service»
«Service»
Restaurant
Management
«Service»
Accounting
«Service»
Kitchen Management
«Service»
Service
«Database»
Database
Uses API
Legend
Part-of
«Service»
API Gateway
«async»
«subscribes to»
«async»
«async»
«async»
«async»
«sync»
«sync»
«sync»
«sync»
«sync»
Implementation Logical
CircleCI deployment
pipeline
«AWS ECR repository»
ftgo-XYZ-service
«Github Repository»
ftgo/ftgo-XYZ-service
Commit
Push
Image
Kubernetes YAML
Kubernetes API
EKS cluster
Commit
3 AZ EKS cluster
Ingress managed ALB
3 AZ RDS Aurora
React application static resources
S3 bucket
api.app.acme.com app.acme.com
Browser
Cloudfront
<<service>> Order management
API Gateway
Managed Apache Kafka
React
SPA
Deployment Repository/

deployment pipeline

@crichardson
Implementation view: diagram
«Service»
Consumer
Management
«Service»
«Service»
Restaurant
Management
«Service»
Accounting
«Service»
Kitchen Management
«Service»
Service
«Database»
Database
Uses API
Legend
Part-of
«Service»
API Gateway
«async»
«subscribes to»
«async»
«async»
«async»
«async»
«sync»
«sync»
«sync»
«sync»
«sync»
Legend!
Stereotypes

@crichardson
Implementation view:
description

@crichardson
Implementation view: services
+ …
<<restaurant events channel>>
«Service»
Delivery Management
«Subdomain»
Delivery Management
«Subdomain»
Courier Management
«CQRS View»
Order History
«Database»
Restaurant
Management
«library»
Tax Calculator
«Service»
Delivery Management
+

@crichardson
Variation: Visualizing subdomain
to service mapping
«Service»
Restaurant Management
«Service»
Order Management
«async»
«Service»
Delivery Management
«Uses»
«Subdomain»
Delivery Management
«Subdomain»
Courier Management
«Subdomain»
Restaurant Management
«Subdomain»
Order Management
Not always 1 to 1

@crichardson
Variation: Visualizing messaging
«Service»
Order Management
«Service»
Restaurant
Management
«subscribes to»
«Service»
Order Management
«Service»
Restaurant
Management
<<restaurant events channel>>
«subscribes to»
Channel Restaurant events
Ordered Yes
Delivery At-least once
Subscription Durable
… …

@crichardson
Variation: Visualizing shared libraries
«Service»
Order Management
«Service»
Accounting
«Service»
Service
«Database»
Database
Uses API
Legend
Part-of
«async»
«library»
Money
«library»
Tax Calculator
«Uses»
«Uses»
Anti-pattern: tight
coupling
Probably ok

@crichardson
Variation: Visualizing shared
databases
Anti-pattern: tight
coupling
«Service»
Order Management
«Service»
Restaurant
Management
«Service»
Service
«Database»
Database
Uses API
Legend
Part-of
«async»
«Database»
Restaurant
Management
«Uses»

@crichardson
Variation: Visualizing CQRS views
«Service»
Order History
«Service»
Order Management
«CQRS View»
Order History
«Service»
Kitchen Management
«Service»
Delivery Management
«Subscribes to»
«Subscribes to»
«Subscribes to»

@crichardson
Implementation view scenario:
collaborating services and entities
Clari
fi
es

@crichardson
Logical view: diagram
«subdomain»
Subdomain A
«subdomain»
Subdomain B
Uses
Legend

@crichardson
Logical view: description

@crichardson
Logical view scenario:
Collaborating classes/subdomains

@crichardson
Process/Deployment view <=>
Modern K8S or Serverless?!

@crichardson
Deployment: K8S cluster/AWS
3 AZ EKS cluster
Ingress managed ALB
3 AZ RDS Aurora
React application static resources
S3 bucket
api.app.acme.com app.acme.com
Browser
Cloudfront
<<service>> Order management
API Gateway
Managed Apache Kafka
React
SPA

@crichardson
Deployment view: description
ReactJS frontend served by Cloudfront from S3 bucket

Application services (+ API Gateway) deployed on AWS EKS:
K8S service + deployment

API entry point = K8S Ingress managed ALB

AWS resources (EKS, RDS Aurora, MKS, …) deployed to
three availability zones

@crichardson
Deployment view: scenario
Browser
React
SPA
Ingress managed ALB API Gateway Order Service
POST /orders
POST /orders
POST /orders

@crichardson
Repository and deployment
pipeline view
CircleCI deployment
pipeline
«AWS ECR repository»
ftgo-XYZ-service
ftgo/ftgo-XYZ-service
Commit
Push
Image
Kubernetes YAML
Kubernetes API
EKS cluster
Commit
Per-service
Per-cluster

@crichardson
Vision
FTGO is a food delivery application.
Consumers use FTGO to place food orders at
local restaurants.

FTGO coordinates a network of couriers who
deliver the orders. It’s also responsible for
paying couriers and restaurants.

Restaurants use the FTGO website to edit
their menus and manage orders.

Architecturally signi
fi
cant user
stories/scenarios
Capture the essence of the
application

In
fl
uence the architecture:

Complex, e.g. span multiple
subdomains

Business critical/highly
available

Low latency

Process large amounts of data

….

@crichardson
BDD-style scenarios: precise description
of behavior in terms of business entities
Givens = pre-conditions
Thens = post-conditions
De
fi
nes “request”

@crichardson
Business
objects
Distill scenarios into system
operations
FTGO
Application
createOrder()
fi
ndOrder()
…
Via UI
Application
Invokes
Subscribes to
Triggers
Model application behavior
cancelOrder()
≪commands≫

≪queries≫
…
Mutates and queries
Business
objects

@crichardson
Non-functional requirements
Quality category Quality Description
Availability Tier 1 (highest) Order
fl
ow
Tier 2 (medium) Account management
Tier … …
Performance Throughput …
Latency …
… … …

@crichardson
Documenting services:
microservice canvas
https://github.com/cer/microservice-canvas

@crichardson
Documenting services:
domain model

@crichardson
Architecture Decision
Records: documenting why
https://github.com/joelparkerhenderson/architecture-decision-record

@crichardson
Summary
The software architecture of a computing system is the set of
structures needed to reason about the system

Architecture is multi-dimensional

Each dimension is described by a view

View = elements + relations + their properties = pictures and words

Documenting architecturally signi
fi
cant user stories/scenarios is
essential

Scenarios animate the elements of a view and connect it to
functional requirements

@crichardson
@crichardson chris@chrisrichardson.net
Questions?

Scenarios_and_Architecture_SkillsMatter_April_2022.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Scenarios_and_Architecture_SkillsMatter_April_2022.pdf

Similar to Scenarios_and_Architecture_SkillsMatter_April_2022.pdf (20)

More from Chris Richardson

More from Chris Richardson (12)

Recently uploaded

Recently uploaded (20)

Scenarios_and_Architecture_SkillsMatter_April_2022.pdf