73
OUR WAY TO MICROSERVICES Supported By: DDD – CQRS - ES

Our way to microservices

Embed Size (px)

Citation preview

Page 1: Our way to microservices

OUR WAY TO MICROSERVICES

Supported By:

DDD – CQRS - ES

Page 2: Our way to microservices

Supported By:

I’M ANDI PANGERAN

@andi_pangerancybercoding.wordpress.com

Page 3: Our way to microservices

Supported By:

Page 4: Our way to microservices

Not that way…

Supported By:

Page 5: Our way to microservices

What we need right now is..

Supported By:

Page 6: Our way to microservices

Refactoring our logic

Supported By:

Page 7: Our way to microservices

AGENDA DOMAIN DRIVEN DESIGN

COMMAND QUERY RESPONSIBILITY SEGREGATION

EVENT SOURCING

AMQP MESSAGING

PROFT OF CONCEPT, SPRING BOOT + AXON FRAMEWORK

Supported By:

Page 8: Our way to microservices

DOMAIN DRIVEN DESIGN

Supported By:

Introduction

Page 9: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGN

• .. For most software projects, the primary focus should be on the domain and domain logic.

Page 10: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGN

Page 11: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNDESIGN

STRATEGIC DESIGN

TACTICAL DESIGN

Page 12: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNDESIGN

STRATEGIC DESIGN

Bounded Context

Ubiquitouse Language

Context Map

Page 13: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNBounded Context

General Ledger

Account Payable

Account Recieveable

AssetsManagement

InventoryBudgetControl

Accounting Application

Page 14: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNUbiquitous Language

DOMAIN EXPERT

Developer

Page 15: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNContext Map

Context mapping is a design process where the contact points and translations between bounded contexts are explicitly mapped out. Focus on mapping the existing landscape, and deal with the actual transformations later.

?Relation

General Ledger

Account Payable

Page 16: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNShared Kernel

Page 17: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNRelation Pattern

Open House Services

Customer – Supplier

Anti Corruption Layer

Page 18: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNStrategic Design

Page 19: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNDESIGN

Entity

Value Object

Aggregates

Domain Events

Layered Architecture

TACTICAL DESIGN

Page 20: Our way to microservices

Supported By:

Entity & Value Object

Entity…

An object fundamentally defined not by its attributes, but by a thread of continuity and identity.

Value Object…

An immutable object that describes some characteristic or attribute but carries no concept of identity.

Page 21: Our way to microservices

Supported By:

Aggregate

Cluster of associated objects that are treated as a unit for the purpose of data changes.

Aggregate enforce concictency

Order Line Items

Customer

Shipping Address

Aggregate Root

Page 22: Our way to microservices

Supported By:

Domain Events

Something meaningful that happened in the Domain…

Communicating state changes of Aggregates…

Immutable Value Objects

Page 23: Our way to microservices

Supported By:

Layered Architecture

Domain

Application

Infrastructure

Web

Por

ts

HTTP

Re

ques

t

Rest

Cont

rolle

rW

ebso

cket

Cont

rolle

rCo

mm

and

Hand

ler

Entity

Value Object

Repository

JPA

REPO

SITO

RY

SQL

DATA

BASE

Pers

iste

nce

Port

s

RABBITMQ

Messaging Ports

(AMQP)

EVENT (PUB – SUB)

Page 24: Our way to microservices

Supported By:

DOMAIN DRIVEN DESIGNTactical Design

Page 25: Our way to microservices

Refactoring ?

Supported By:

Page 26: Our way to microservices

CQRS

Supported By:

Introduction

Page 27: Our way to microservices

Supported By:

CQRS

Pioneered by Greg Young & Udi Dahan

In this context, » Commands = Writes» Queries = Reads

Command/Query Responsibility Segregation (CQRS) is the idea that you can use a different model to update information than the model you use to read information.

Page 28: Our way to microservices

Supported By:

CQRS

But why?

Page 29: Our way to microservices

Supported By:

Why Is CQRS needed ?

Read vs Write Capacity…

Scale read operations differently from write operationsSplit the concerns…

Simplicity in domain model by separating read and writes.

Decreased COMPLEXITY…

Write need validation and consequential logic.

Read have many representation model, and storage mechanism (polyglot storage)

Page 30: Our way to microservices

Supported By:

How Does CQRS work ?

Persistent View Model schema matches UI view model

Scale out as many copies as needed

Command captures the intent of the user

Commandbus deliver command to command

handler

A queue can be utilized to optimize write performance

After database is updated, publish result

to view model via eventbus

Page 31: Our way to microservices

Supported By:

How Does CQRS work ? Command

Commands encapsulate the user’s intent but do not contain business logic, only enough data for the command.

Command message handled by command handler.

Just once command handler / command message.

Command handler can reject a command, validation / bussines rules violation

Page 32: Our way to microservices

Supported By:

How Does CQRS work ? Event

Events describe changes in the system state.

An Event Bus can be utilized to dispatch events to subscribers.

Events primary purpose update the read model

Events can also provider integration with external systems

CQRS can also be used in conjunction with Event Sourcing.

Page 33: Our way to microservices

Event Sourcing

Supported By:

Introduction

Page 34: Our way to microservices

Supported By:

Traditional systems store current state

INSERT INTO charging_stationsVALUES (“CP001”, “Acme Corp.”, “Widget B”);

INSERT INTO charging_stationsVALUES (“CP003”, “ABC Widgets”, “Model-1”);

UPDATE charging_stationsSET model = “Widget A”WHERE identity = “CP001”;

Page 35: Our way to microservices

Supported By:

Traditional systems store current state

Page 36: Our way to microservices

Supported By:

Traditional systems store current state

keeping only the current state…

lot of valuable historic data is lost, e.g. the information about the time a state change happened, who invoked the change, and so on. This historic data may remind you of something called an audit log.

conceptual model…

there is no single model that could be used universally for every possible case that the system needs to address. Moreover, the structure of the application data tends to change overtime..

Page 37: Our way to microservices

Supported By:

Store the sequence of events that led up to the current state.

Page 38: Our way to microservices

Supported By:

populate the application state via projection

Page 39: Our way to microservices

Supported By:

Snapshoting

SNAPSHOT

Page 40: Our way to microservices

CQRS

Supported By:

Back to

Page 41: Our way to microservices

Supported By:

How Does CQRS work ? Persistent View Model

Read model can be denormalized RDBMS, document store, etc.

Optimize read model with different data storage technologies for different kinds of data (polyglot)

Eventually Concistence

Page 42: Our way to microservices

Supported By:

How do we apply the Concepts ?

Page 43: Our way to microservices

Supported By:

CORE

Page 44: Our way to microservices

Supported By:

CORE

Page 45: Our way to microservices

Supported By:

CORE

Page 46: Our way to microservices

Supported By:

CTM CORE

Page 47: Our way to microservices

Supported By:

CORE

Page 48: Our way to microservices

Supported By:

CTM CORE

Page 49: Our way to microservices

Supported By:

CORE

Page 50: Our way to microservices

Advanced Message Queuing Protocol (AMQP)

Supported By:

Introduction

Page 51: Our way to microservices

Supported By:

AMQP IN A NUTSHELL

A producer is a user application that sends messages

A exchange is message router that routes message to queue. There is Direct, Fanout, Topic Exchange

A queue is a buffer that stores messages

A consumer is a user

application that receives

messages.

Page 52: Our way to microservices

Supported By:

Fanout Exchange

A fanout exchange routes messages to all of the queues that are bound to it and the routing key is ignored. If N queues are bound to a fanout exchange, when a new message is published to that exchange a copy of the message is delivered to all N queues. Fanout exchanges are ideal for the broadcast routing of messages.

Page 53: Our way to microservices

Supported By:

Direct Exchange

A direct exchange delivers messages to queues based on the message routing key

Page 54: Our way to microservices

Supported By:

Topic Exchange

Topic exchanges route messages to one or many queues based on matching between a message routing key and the pattern that was used to bind a queue to an exchange.

Page 55: Our way to microservices

Supported By:

Sample Spring AMQP Configuration

Page 56: Our way to microservices

Axon Framework

Supported By:

Introduction

Page 57: Our way to microservices

Supported By:

Why Axon Framework

Compatibility with CQRS and ES …

Axon Framework is a Java Framework for scalable and high performance applications and being focused on making life easier for developers that want to create applications based on the CQRS principles and concepts, i.e. commands, events, aggregates, entities, sagas, etc. On top of that, it also supports event sourcing.

Integrability…

It supports the Spring Framework's configuration and dependency injection. It also uses Java annotations for building the domain model and event listeners without being tied to the Axon's specific logic.

Active development and support…

the latest version at the time of writing this was 2.4.4. It is actively developed, a new major version 3 is a work in progress. It has nice and detailed documentation and a sample project to showcase the code. The authors also provide commercial services such as support contracts, training, and consultancy.

Popularity…

The code repository on GitHub has more than 300 stars and 100 forks. The user community is active on the mailing lists and on the issue tracker.

Page 58: Our way to microservices

Supported By:

Axon FrameworkCommandBus

SimpleCommandBus…

It does straightforward processing of commands in the thread that dispatches them. After a command is processed, the modified aggregate(s) are saved and generated events are published in that same thread.

AsynchronousCommandBus …

It does processing of commands in new thread. After a command is processed, the modified aggregate(s) are saved and generated events are published in that same thread.

DisruptorCommandBus …

The DisruptorCommandBus takes a different approach to multithreaded processing. Instead of doing the processing in the calling thread, the tasks are handed off to two groups of threads, that each take care of a part of the processing. The first group of threads will execute the command handler, changing an aggregate's state. The second group will store and publish the events to the Event Store and Event Bus.

Page 59: Our way to microservices

Supported By:

Axon FrameworkSimpleCommandbus Configuration

Page 60: Our way to microservices

Supported By:

Axon FrameworkAsynchronousCommandBus Configuration

Page 61: Our way to microservices

Supported By:

Axon FrameworkDisruptorCommandBus Configuration

Page 62: Our way to microservices

Supported By:

Axon FrameworkEventBus

SimpleEventBus …

The SimpleEventBus just dispatches each incoming Event to each of the subscribed EventListeners sequentially. If an EventListener throws an Exception, dispatching stops and the exception is propagated to the component publishing the Event..

ClusteringEventsBus …

The ClusteringEventsBus allows application developers to bundle EventListeners into Clusters based on their properties and non-functional requirements. The ClusteringEventBus is also more capable to deal with Events being dispatched among different machines. Contains two mechanisms: the ClusterSelector, which selects a Cluster instance for each of the registered EventListeners, and the EventBusTerminal, which is responsible for dispatching Events to each of the relevant clusters..

Page 63: Our way to microservices

Supported By:

Axon FrameworkSimpleEventBus Configuration

Page 64: Our way to microservices

Supported By:

Axon FrameworkClusteringEventBus Configuration

Page 65: Our way to microservices

Supported By:

Axon FrameworkEvent Store

FileSystemEventStore…

The FileSystemEventStore stores the events in a file on the file system. It provides good performance and easy configuration. Not a suitable implementation for production environments

JpaEventStore …

The JpaEventStore stores events in a JPA-compatible data source. Unlike the file system version, the JPAEventStore supports transactions. The JPA Event Store stores events in so called entries. To use the JpaEventStore, you must have the JPA (javax.persistence) annotations on your classpath..

JDBC Event Store …

The JDBC event store uses a JDBC Connection to store Events in a JDBC compatible data storage. Typically, these are relational databases. Theoretically, anything that has a JDBC driver could be used to back the JDBC Event Store.

MongoDB Event Store …

Use mongodb to store Events.

Page 66: Our way to microservices

Supported By:

Axon FrameworkJdbcEventStore Configuration

Page 67: Our way to microservices

Supported By:

Axon FrameworkMongoDb EventStore Configuration

Page 68: Our way to microservices

Supported By:

Axon FrameworkAggregate Repositories

GenericJpaRepository…

This is a repository implementation that can store JPA compatible Aggregates. It is configured with an EntityManager to manage the actual persistence, and a class specifying the actual type of Aggregate stored in the Repository.

EventSourcingRepository …

The EventSourcingRepository implementation provides the basic functionality needed by any event sourcing repository in the AxonFramework.

HybridJpaRepository…

The HybridJpaRepository is a combination of the GenericJpaRepository and an Event Sourcing repository. It can only deal with event sourced aggregates, and stores them in a relational model as well as in an event store. When the repository reads an aggregate back in, it uses the relational model exclusively..

Page 69: Our way to microservices

Supported By:

Axon FrameworkSample Repository Configuration

Page 70: Our way to microservices

Spring Boot + Axon Framework

Supported By:

Proft Of Concept

Page 71: Our way to microservices

QUESTIONS ?

Supported By:

Page 72: Our way to microservices

Supported By:

Recommended Reading

Page 73: Our way to microservices

Thanks

Supported By: