Implementing Microservices by DDD

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Kim Kao, Solutions Architect
Mar 13, 2019
Implementing Microservices by DDD
DDD – A collaboration way to go

A typical day for a customer new to AWS...
Manager -
“We are going to run workload(s) on AWS.
We have new sub-systems/module to develop with legacy services.
Container is good, Lambda is awesome. It’s great to have whole
cloud native advantage if you guys migrate all service into
microservice, serverless...”
Developer - “Not a problem. I’ll make it …”

Business Wants
https://vaughnvernon.co/tag/event-storming/

But You Want
https://vaughnvernon.co/tag/event-storming/

Challenge on migration to Microserivces
• Legacy looks like Big ball of mud(BBOM)
• Heavy dependency with external system
• No idea on splitting BBOM
• No idea to find out system boundary
• Which service(s) worth to do
• Human resources allocation
• Team, out sourcing, ISVs solution

What are Microservices?

= Microservices ?

100/200/300/1000?
LOC

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
What Are Microservices?
“A software architecture style in which complex
applications are composed of small, independent
processes communicating with each other using language-
agnostic APIs. These services are small, highly decoupled
and focus on doing a small task, facilitating a modular
approach to system-building.” - Wikipedia
https://en.wikipedia.org/wiki/Microservices

Way to divide services from Monolith
• By noun(s)
• By Your Experience(s)
• By Team’s decision
• Up to Leader/Manager/CxO ...
• No right or power to influence

Case study - Gilt
Problem behind Microservices

Gilt
The limited-selling website for limited time purchases, the flash purchase start time is except for 9
:00 pm on Wednesday and Sunday, and the rest are sold at 12 noon in the US East, lasting 36-48
hours and then off the shelf. Popular brands usually go out quickly.

Monolith
Load
Balancer
Account Service
Cart Service
Shipping Service
StoreFront UI
Browser
Database
Data Access
Service

Account
Database
Inventory
Database
Shipping
Database
Migrate to Microservices
Load
Balancer
StoreFront
UI
Browser
Account
Service
Cart Service
Shipping
Service
Load
Balancer
Load
Balancer
Load
Balancer

Challenge is Coming
• Authentication & Authorization
• Session mechanism is broken
• Centralized & Robust alternative one is required
• Service Discovery
• Write the traffic routing code(s) in logic?
• Re-try, Failover, Caching, ...
• Persistence
• Isolated Persistence for each Service

A Classic solution on AWS
Load
Balancer
StoreFront
UI
Browser
Account
Database
Account
Service
Cart Service Inventory
Database
Shipping
Service
API
Gateway
Load
Balancer
Load
Balancer
Load
Balancer
Shipping
Database

Authentication & Authorization
• Token based solution fit in
• Cognito
• 3rd party Authentication Federation
• Amazon, Google, Apple, Facebook...
• Self developed/hosted centralize A&A
services

Service Discovery
• Client Side-Service Discovery
• Application Load Balancer-based Service
Discovery
• DNS-Based Service Discovery
• Service Discovery using ECS Event
Stream
• Configuration Management
• New * App Service Mesh (preview)
• Cloud Map

Microservices
For Persistence ?
Stateful Persistent always be the top issue !!!

• Accept all API calls to one RDS Cluster
• RDS Instance Sizing predict by services scaling ability
• DBA(s) : How to manage Connection Pool ?
• Read replica can’t help on Write intention
• RDS I/O be the bottleneck when highly Scale up
• All Services impacted while any failure occurred
• Option : Upgrade Read Replica to Master
Launching 1 RDS cluster

Launching N * RDS for Independency?

• DynamoDB
• Perfect deal with high transaction (write)
• Serve each table for only one transaction/service intention
• De-Normalize schema is required
• Prevent revision issue
• Hard to do complexity Join Query
• Cost High
• Low Performance
• Coding for iteration & aggregation
• Apply all RDS tables into DynamoDB?
Using NoSQL Solution?

It’s about capability
• Are you ready to deal with M:N transaction compensation ?
• Are you ready to embrace the rapidly change by contract ?

Transaction Dependencies between Microservices
• Upstream-Downstream co-relationship
• One Transaction invoke local API and Remote API
Book Rental
Service
Book Flight
Service
Trip Service
Book Hotel
Service
Exception / Error ?
Exception / Error ?
Exception / Error ?
!"
#
!$
#
!#
#
+
+
Transaction Compensate

Saga : Alternative for 2 Phase -commit

Context
• You have applied the Database per Service pattern.
Each service has its own database.
• Some business transactions, however, span multiple
service so you need a mechanism to ensure data
consistency across services.

Problem
How to maintain data consistency across services?

Forces
• 2 Phase-Commit(PC) is a well-known solution for years
• The 2PC coordinator also represents a Single Point of
Failure, which is unacceptable for critical systems

Solutions
• Each local transaction updates self
and publishes a message/event to
trigger the next local transaction in
the saga.
• If a local transaction fails because
it violates a business rule then the
saga executes a series of
compensating transactions that
undo the changes that were made
by the preceding local
transactions.
https://microservices.io/patterns/data/saga.html

Two ways of Saga Pattern
• Choreography - each local transaction publishes
domain events that trigger local transactions in other
services
• Orchestration - an orchestrator (object) tells the
participants what local transactions to execute

Choreography-based Saga
2
1
3.b
3.a
4.a
4.b
• Logic in code
• Compensate chain
• Multiple states present in transaction

Orchestration -based Saga
• Coordinator stand alone
• Each service provide
a pair function for Success or Fail
• Abstract compensate logic
out of Codes1
1.1 2 3
45

Resulting Context
• This pattern has the following benefits:
• It enables an application to maintain data consistency across multiple services without
using distributed transactions
• This solution has the following drawbacks:
• The programming model is more complex. For example, a developer must design
compensating transactions that explicitly undo changes made earlier in a saga.
• There are also the following issues to address:
• In order to be reliable, a service must atomically update its database and publish a
message/event. It cannot use the traditional mechanism of a distributed transaction
that spans the database and the message broker. Instead, it must use one of the
patterns listed below.

Implementing Saga on AWS

AWS Step Functions

• Each Service provide cancel operation
• State change trigger cancel operation
• Simplify Complexity rules
• Just a JSON file

Code snippet
https://github.com/humank/lambda-saga-pattern

How to adopt Microservices?

Business operation without whole picture
The Blind Men and the Elephant
Is It correct to all in microservices or serverless ?

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Precondition to do microservices
Rapid Provisioning
Basic monitoring
Rapid application deployment
Martin
Fowler

Better way to decompose Monolith
Domain
Expert
Matters

How to break Monolith?

Methodology -1
Use Case Modeling

Methodology -2
ICONIX Processing

Object Modeling …
ER Modeling …
xxx Modeling …
A lack of Collaboration with non-tech stakeholders
Not “Ubiquitous Language”

Way to collaborate
• Point out the events
• Who send the command
• Find the Noun(s)
• Have all team voices
Commands
Events
Aggregate

Domain Driven Design

Domain Driven Design (DDD)
• What is DDD?
• Not only a Technology / Methodology
• Set of principles and patterns for focusing the design effort
where it matters most
• It’s all about
• Understanding the domain where the software will be
applied
• Create highly expressive model of that domain
• Distil Ubiquitous language

Modeling - Intent matters

Domain (Strategy) Modeling – Basic Terms
• Domain
• Subject area where the software will be applied
• Example : VOD Domain, EC Domain, Banking
Domain
• Subdomain
• Logically separated part of the Domain
• Example : Ingestion, Streaming, Geo Location
• Domain Model
• Software model for solution of a domain
problem
• Bounded Context
• Explicit boundary where Domain Model lives

Domain is about capability
Grab key events to
Abstraction to give

Dive into relationships and why
Strategic DDD

Pattern in Practice
Tactical DDD

Approach
• Collect the “Aggregates” which stand for similar
concept in the “Bounded Context”.
• Prioritize the “Domains”, which one is Core Domain,
rest for Sub Domain, even Utility Domain.
• Get Consensus, not Compromise
• Focus on Core Domain

Coffee shop experience
DDD by EventStorming

Go through Event Storming approach
Don’t tell tech only
Don’t sell tech partially
Aim for Core value
Figure out trigger
and result

Seat
occupied
Menu offered
Ordered 2 cups
of Americano
Paid
Order
received
Coffee
made up
Customers
Left
Table
Cleaned
*Key Business Events in Coffeeshop

Event Trigger
• Client
• Server
• Counter
• Barista
ACTORS

Most Valuable / Risky Events

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Order
Make Up
Payment
Event Bus
(pub/sub)
Put
event
Event
Event
CloudWatch Event
.
.
.
Any other messaging
technology
Coffee shop Domain implementation Core Domain
Sub Domain
(Messaging)
Support Domain
Core Domain

When you should dive in Microservices
Team
Partners
Business
Operation
Coding
Value

How DDD can help you
• Business strategy on resource allocation
• Best resources should be put in most key/core domain
• Buy or out-sourcing common domain and sub domain
• Service re-architecture
• Form up the system context boundary
• Knowing the upstream-downstream relationship between
domains
• Meaningful to do microservice (separate computing/persist,
and API communication )
• Service Migration
• Good to re-architecture

Take Away
Know Why/What/How
• Do you really need Microservices?
• Leverage Business Events to aggregate
context and form up Service Boundary
• There is no C4 to solve distributed persistence
issue
• State Machine to do Transaction Compensate
(Step Functions way to go)
• DDD is good to collaborate Business and
Technology guys by speaking Ubiquitous
Language
• Crunch Problem, then design solution

Implementing DDD on AWS
AWS : YikaiKao@amazon.com
Commounty : DDD Taiwan@FB
Telegram : YikaiKao
WeChat : YikaiKao
Twitter : @YikaiKao
GitHub Repos

Implementing Microservices by DDD

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Implementing Microservices by DDD

Similar to Implementing Microservices by DDD (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Implementing Microservices by DDD