All the cool kids....

98
Yeah, they're invincible, and she's just in the background And she says: “I wish that I could be like the cool kids.”

Transcript of All the cool kids....

Page 1: All the cool kids....

Yeah, they're invincible, and she's just in the background

And she says:

“I wish that I could be like the cool kids.”

Page 2: All the cool kids....

All the cool kids…@matthiasnoback

CTO at

Page 3: All the cool kids....

What is cool?

NoSQL?

Page 4: All the cool kids....

?

?

Page 5: All the cool kids....

?

Page 6: All the cool kids....

http://nosql-database.org/

What’s this?

Page 7: All the cool kids....
Page 8: All the cool kids....

Conclusion: Use “cool” things when you understand them

Page 9: All the cool kids....

What else is cool?

JavaScript?

Page 10: All the cool kids....

?

??

?

?

Page 11: All the cool kids....

Conclusion: Use “cool” things that last

Page 12: All the cool kids....

Not what this talk is about

Page 13: All the cool kids....

DDD

BDD

Microservices

CQRS/ES

Hexagonal architecture

Page 14: All the cool kids....

These things are “cool” But they aren’t a hype

They have a proven track record

Page 15: All the cool kids....

Why do we need to talk about them again?

Page 16: All the cool kids....

Serious psychological impediments

“I want to do what they do”“I’m scared”

“I’m doing quite well”“You can’t have it all”

Page 17: All the cool kids....

To be honest

Page 18: All the cool kids....

Our projects may be

Too simple Too small

Too short-lived Too much time-constrained

Page 19: All the cool kids....

Overcoming anxiety

You can do it! You’ll get used to it

You could do much betterThere are “light” options

Page 20: All the cool kids....

You just need to:

Listen Read

Practice

Page 21: All the cool kids....

About DDDdomain-driven design

Eric Evans

Page 22: All the cool kids....

Tactical patterns

Page 23: All the cool kids....

Entities

Locus of change

Identifiable

Can act as the root of a bigger aggregate

Page 24: All the cool kids....

Value Objects

Immutable

Describe aspects of an entity

Page 25: All the cool kids....

Aggregates

Compositions of Entities and Value Objects

Transactional boundary

Page 26: All the cool kids....

Repositories

Act as collections of aggregates

Page 27: All the cool kids....

Domain Events

Immutable

Notification of change inside an entity

Page 28: All the cool kids....

What changes?

We don’t design with the database in mind (we design the objects)

We don’t calculate change sets anymore (we only touch one aggregate)

Page 29: All the cool kids....

So far, much of DDD is just “better programming”

Page 30: All the cool kids....
Page 31: All the cool kids....

Ubiquitous Language

The language spoken by both software developers and business people

Prevents translations between business and implementation domain language

central to DDD

Page 32: All the cool kids....

Core Domain

The aspect of the business domain that is distinctive

Good software should make a big difference here

Page 33: All the cool kids....

Generic subdomain

The software for this can be a standard solution or outsourced

Page 34: All the cool kids....

Bounded Context

There is a boundary for domain models

The meaning and relevance of concepts ends at the boundary

Allows for separate teams to work on a model

Page 35: All the cool kids....

Strategic patterns

Page 36: All the cool kids....

This is so very useful

Page 37: All the cool kids....

Which bounded contexts exist?

How do they map to (sub)domains of the

business? What are the

relationships between the teams responsible for

them?

Page 38: All the cool kids....

This is where we can vastly expand our horizons

Page 39: All the cool kids....

Event storming

Page 40: All the cool kids....

Interviewing domain experts

Page 41: All the cool kids....

Crunch domain knowledge

Grow a model

Refine a model

Make it do useful work

“software that matters”

agile

Page 42: All the cool kids....

As a software developer you should be cool and be part of this movement

Page 43: All the cool kids....
Page 44: All the cool kids....

About BDD

behavior-driven development

Dan North

Page 45: All the cool kids....

I want…

Okay

stakeholder programmer

Agile!

Page 46: All the cool kids....

What’s the next most important thing the system doesn’t do?

heuristic

Page 47: All the cool kids....

As a … I want to … So that …

user story

Page 48: All the cool kids....

Given … When … Then …

Given … When … Then …

Given … When … Then …

scenarios, examples, acceptance criteria

Page 49: All the cool kids....

Given … When … Then …

Make executable

Page 50: All the cool kids....

–Dan North

“BDD is about implementing an application by describing its

behavior from the perspective of its stakeholders”

Page 51: All the cool kids....

Write a failing acceptance test

Write a failing unit test

Make the test pass

Page 52: All the cool kids....

BDD is an agile methodology for creating software that matters

Page 53: All the cool kids....

Ubiquitous language

Expected behavior

Requirements analysis

Domain experts

Acceptance criteria

just like with DDD!

Page 54: All the cool kids....

Testing and the tools are only of “secondary” interest

but great nonetheless!

Page 55: All the cool kids....

Modelling by Example

Konstantin Kudryashov

Page 56: All the cool kids....

Design your domain model guided by examples

Page 57: All the cool kids....

Domain

Application

Infrastructure

database

UI

HTTP

filesystem

Page 58: All the cool kids....

Test your scenario’s against the application or domain layer

Domain

Application

Page 59: All the cool kids....

Run some scenario’s against the infrastructure layer

Domain

Application

Infrastructure

Page 60: All the cool kids....

Unit

Acceptance

UICiaran McNulty

Page 61: All the cool kids....

BDD, modelling by example: cool and very helpful for reaching the goals set by DDD

Page 62: All the cool kids....

About CQRS and Event Sourcing

Page 63: All the cool kids....

First: what’s CQS

command query separation

Bertrand Meyer

Page 64: All the cool kids....

class Entity{ private $information; public function changeInformation($information) { $this->information = $information; } public function getInformation() { return $this->information; } }

command function

query function

Page 65: All the cool kids....

Second: what’s CQRS

command query responsibility segregation

Greg Young

Page 66: All the cool kids....

class Entity{ private $information; public function changeInformation($information) { $this->information = $information; } } class ReadModel{ private $information; public function getInformation() { return $this->information; } }

command function

query function

Page 67: All the cool kids....

Entity

ReadModel

Database

“CQRS lite”

Page 68: All the cool kids....

Entity

ReadModel

Database

Database

?

Page 69: All the cool kids....

Domain events!

just like with DDD (again)

Page 70: All the cool kids....

Entity

Domain event

ReadModel External serviceReadModel

projection

tailor-made for a particular view

Page 71: All the cool kids....

Entity created

Information changed

Some other event

Yet another event

Event store

Page 72: All the cool kids....

Domain event

Report AnalyticsNew read model

add new subscribers at any time

Page 73: All the cool kids....

Visualise event streams

Jef Claes

Page 74: All the cool kids....

Look into CQRS and ES because:

Your “reads” will be more efficient Your reports/statistics/… are very valuable for you/your clients

It fits very well with DDD

It makes your application ready for the next challenge…

Page 75: All the cool kids....

About Microservices

Sam Newman

Page 76: All the cool kids....

Something known as a monolith

Page 77: All the cool kids....

Micro-service

Micro-service

Micro-service

Micro-service

Micro-service

better!

Page 78: All the cool kids....

Micro-service

Micro-service

Micro-service

Micro-service

Micro-service

Page 79: All the cool kids....

Micro-service

Command

Event

Command

Event

loose coupling (dependency inversion)

Page 80: All the cool kids....

Micro-service

Storage

Decentralized data

Page 81: All the cool kids....

Micro-service

Service-oriented

Command

Query

Page 82: All the cool kids....

Micro-service

Event

Event-driven

Page 83: All the cool kids....

Micro-service

Ideally mapped to Bounded Contexts

Yes… DDD!

Page 84: All the cool kids....

Micro-serviceMicro-service

Replaceable

Page 85: All the cool kids....

Micro-service

Different technologies

Micro-service

Micro-service

Page 86: All the cool kids....

Microservices done right:

Resilient Redundant

Separately deployable Decoupled

Need a lot of:

Monitoring Automation

Page 87: All the cool kids....

Most importantly: it should fit within your organisation

Cross-functional teams

Different ways of cooperation (Context Map)

A microservice architecture offers scaling options for your developer team

Page 88: All the cool kids....

Ignore all the jokes on Twitter and look into this cool thing

Page 89: All the cool kids....

The cool kids

Page 90: All the cool kids....

Who are they?

The people at company X?

Teams who use Y in production?

People who have a Google Friday?

Companies with picknick tables and fake grass?

People with a Raspberry Pi continuous deployment

pipeline?

Page 91: All the cool kids....

It turns out… you are the cool kids

Page 92: All the cool kids....

You know more than you think You do special things

You’re beautiful

Page 93: All the cool kids....

Share what you do

interesting!wow!

aha!

Page 94: All the cool kids....

Push yourself to the limit

Page 95: All the cool kids....

Learn about the cool stuff that’s here to stay

DDD BDD

Microservices

CQRS/ES

Hexagonal

Page 96: All the cool kids....

Abstract the fashionable details

Page 97: All the cool kids....

Thank you!

legacy.joind.in/16397

Page 98: All the cool kids....

Recommended reading

Domain Driven Design (Eric Evans)

Implementing Domain Driven Design (Vaughn Vernon)

Growing Object-Oriented Software Guided by Tests (Steve Freeman & Nat Pryce)

Microservices (Sam Newman)

Modelling by Example (Konstantin Kudryashov)