Growing Hexagonal Microservices by TDD

Slide 1

Slide 1 text

lemi orhan ergin co-founder, HEXAGONAL MICROSERVICES GROWING with tdd ali can akkuş software crafter,

Slide 2

Slide 2 text

lemi orhan ergin co-founder, ali can akkuş software crafter, developing products, Craftbase alumni, Sony, eBay, ACM, iyzico founder, Software Craftsmanship Turkey programming, since 2001 with love speakerdeck.com/lemiorhan @lemiorhan developing products, Craftbase alumni, 32bit, iyzico practitioner, extreme programming jvm stack, java, groovy, spring alicanakkus.github.io @Alican_Akkus

Slide 3

Slide 3 text

Layered architecture Web Domain Persistence From a certain layer, we can only access components in the same layer or in a layer below. LAYERS OF Isolation

Slide 4

Slide 4 text

Web Domain Persistence CONSIDERED HARMFUL Layered architecture

Slide 5

Slide 5 text

Application

Slide 6

Slide 6 text

No way to understand what the code is about Domain logic is sca!ered throughout the layers Hard to understand where domain logic is Layers encourage horizontal coupling DDD do not work on partitioned architecture Many uncategorized components Application

Slide 7

Slide 7 text

Your architectures should tell readers about the system, not about the frameworks you used in your system. SCREAMING ARCHITECTURE https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html Screaming Architecture, Robert C. Martin Application

Slide 8

Slide 8 text

Web Domain Persistence Architecture sinkhole anti-pa!ern The fast lane reader anti-pa!ern You have to be self-disciplined Domain logic sca!ered throughout the layers Database/state drives the design Uncategorized helper and utility classes Monolith in nature Changing existing code instead of adding new Hard to change over time When it grows, it’s hard to test Open for hacking your own code Documentation is critical The Inconvenient truth

Slide 9

Slide 9 text

Robert C. Martin Author of Clean Code and Clean Coder Owner of cleancoders.com training site The very first value of so"ware is to tolerate and facilitate on-going changes

Slide 10

Slide 10 text

Make future changes easy No chain reaction of modification Big impact with few changes No workarounds or “just once” hacks Avoid accidental complexity Easy testing and verification MAINTAINABILITY The very first value of so"ware is to tolerate and facilitate on-going changes

Slide 11

Slide 11 text

Immune to technical evolution Easy to add new integrations Delay technological decisions Testability in isolation Framework independent domain FLEXIBILITY The very first value of so"ware is to tolerate and facilitate on-going changes

Slide 12

Slide 12 text

A timeless goal of so"ware engineering has been to separate code that changes frequently from code that is stable. James Coplien Quote from his „Lean Architecture‰ book

Slide 13

Slide 13 text

A timeless goal of so"ware engineering has been to separate code that changes frequently from code that is stable. DOMAIN INFRASTRUCTURE Business logic Constraints and Behaviors What we really care about Integrations with infra components Technology and framework dependent How we make domain work

Slide 14

Slide 14 text

A timeless goal of so"ware engineering has been to separate code that changes frequently from code that is stable. DOMAIN INFRASTRUCTURE Heart of the so!ware The detail

Slide 15

Slide 15 text

Image Credit: Benoit Hediard, https://medium.com/@benorama/ the-evolution-of-software-architecture-bd6ea674c477

Slide 16

Slide 16 text

Credit: https://twitter.com/lemiorhan/status/1077894094402277376 Image Credit: Benoit Hediard, https://medium.com/@benorama/ the-evolution-of-software-architecture-bd6ea674c477

Slide 17

Slide 17 text

domain HEXAGONAL ARCHITECTURE IN A NUTSHELL

Slide 18

Slide 18 text

domain inside outside

Slide 19

Slide 19 text

infra domain main component framework layer running at startup and builds the whole system technology agnostic core of application contains constraints and behaviors of the domain technology dependent layer that interacts with external devices via integration points

Slide 20

Slide 20 text

infra domain Dependencies are from outside to inside

Slide 21

Slide 21 text

infra domain interface implementation use implement

Slide 22

Slide 22 text

infra domain port adapter use implement PORTS AND ADAPTERS

Slide 23

Slide 23 text

user service repository adapter user service repository port DEPENDENCY INVERSION abstractions should not depend on details details should depend on abstractions high-level modules should not depend on low-level modules both should depend on abstractions LOW LEVEL MODULE DEPENDENCY INVERTED DEPENDENCY DIRECTED HIGH LEVEL MODULE

Slide 24

Slide 24 text

infra domain rest api web ui 3rd party apps command line soap calls admin gui batch jobs mobile apps other hexagons THE LEFT SIDE we find the actors who drive the domain adapts requests from the outside to our domain user side, primary adapters

Slide 25

Slide 25 text

infra domain adapter use facade THE LEFT SIDE we find the actors who drive the domain adapts requests from the outside to our domain user side, primary adapters

Slide 26

Slide 26 text

infra domain mysql adapter stripe adapter cache provider elastic search mail server database sms provider message queue other hexagons THE RIGHT SIDE integrations with the components that the application interacts with functionality needed by the application for implementing the business logic framework side, secondary adapters

Slide 27

Slide 27 text

infra domain port adapter use implement THE RIGHT SIDE integrations with the components that the application interacts with functionality needed by the application for implementing the business logic framework side, secondary adapters

Slide 28

Slide 28 text

infra domain mysql adapter stripe adapter rest api web ui

Slide 29

Slide 29 text

infra domain stripe adapter rest api mysql adapter web ui billing search

Slide 30

Slide 30 text

infra stripe adapter rest api mysql adapter web ui domain notification payment order basket restaurant scheduling caching mail account messaging billing search

Slide 31

Slide 31 text

Packages by Features and Well-Defined Bounded Contexts

Slide 32

Slide 32 text

infra domain WHEN & HOW TO WRITE TESTS

Slide 33

Slide 33 text

infra domain adapter use facade model use dto use

Slide 34

Slide 34 text

infra domain adapter use facade mock CONTRACT TESTS test facade dto use model use OUTSIDE-IN TDD

Slide 35

Slide 35 text

io.craftbase.orderapi io.craftbase.orderapi CONTRACT TESTS

Slide 36

Slide 36 text

domain facade port use use model use business logic use

Slide 37

Slide 37 text

domain facade use use model use business logic use port mock TEST DRIVEN DEVELOPMENT main sub-product is unit tests test INSIDE-OUT TDD

Slide 38

Slide 38 text

io.craftbase.orderapi io.craftbase.orderapi UNIT TESTS

Slide 39

Slide 39 text

infra domain adapter implement port use use model entity use email client

Slide 40

Slide 40 text

infra domain adapter implement port use use model entity use email client test FUNCTIONAL AND INTEGRATION TESTS tdd generates unit tests in addition to it mock client fake with wiremock

Slide 41

Slide 41 text

io.craftbase.orderapi io.craftbase.orderapi UNIT TESTS

Slide 42

Slide 42 text

io.craftbase.orderapi io.craftbase.orderapi INTEGRATION TESTS FOR ADAPTERS

Slide 43

Slide 43 text

io.craftbase.orderapi io.craftbase.orderapi INTEGRATION TESTS FOR CONTROLLERS

Slide 44

Slide 44 text

io.craftbase.orderapi io.craftbase.orderapi FUNCTIONAL TESTS VIA CUCUMBER

Slide 45

Slide 45 text

TEST TYPES AT HEXAGONALS Domain Infra Unit Tests Unit Tests Integration Tests Component Tests Contract Tests External Verifier Stub Tests Functional Tests io.craftbase.orderapi io.craftbase.orderapi

Slide 46

Slide 46 text

Evolution starts from big ball of mud, i.e. traditional monoliths

Slide 47

Slide 47 text

infra stripe adapter rest api mysql adapter web ui domain ... to modular monoliths

Slide 48

Slide 48 text

SEARCH ... and evolution continues with emerging micro services

Slide 49

Slide 49 text

SEARCH PAYMENT ... and evolution continues with emerging micro services ... from modular monoliths

Slide 50

Slide 50 text

SEARCH PAYMENT ACCOUNT ... and evolution continues with emerging micro services ... from modular monoliths

Slide 51

Slide 51 text

SEARCH PAYMENT ACCOUNT ... and evolution continues with emerging micro services ... from modular monoliths

Slide 52

Slide 52 text

how you go is always as important as where you go

Slide 53

Slide 53 text

how you go is always as important as where you go @lemiorhan LEMi ORHAN ERGiN @alican_akkus ALİ CAN AKKUŞ