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

And she says:

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

All the cool kids…@matthiasnoback

CTO at

What is cool?

NoSQL?

?

?

?

http://nosql-database.org/

What’s this?

Conclusion: Use “cool” things when you understand them

What else is cool?

JavaScript?

?

??

?

?

Conclusion: Use “cool” things that last

Not what this talk is about

DDD

BDD

Microservices

CQRS/ES

Hexagonal architecture

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

They have a proven track record

Why do we need to talk about them again?

Serious psychological impediments

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

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

To be honest

Our projects may be

Too simple Too small

Too short-lived Too much time-constrained

Overcoming anxiety

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

You could do much betterThere are “light” options

You just need to:

Listen Read

Practice

About DDDdomain-driven design

Eric Evans

Tactical patterns

Entities

Locus of change

Identifiable

Can act as the root of a bigger aggregate

Value Objects

Immutable

Describe aspects of an entity

Aggregates

Compositions of Entities and Value Objects

Transactional boundary

Repositories

Act as collections of aggregates

Domain Events

Immutable

Notification of change inside an entity

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)

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

Ubiquitous Language

The language spoken by both software developers and business people

Prevents translations between business and implementation domain language

central to DDD

Core Domain

The aspect of the business domain that is distinctive

Good software should make a big difference here

Generic subdomain

The software for this can be a standard solution or outsourced

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

Strategic patterns

This is so very useful

Which bounded contexts exist?

How do they map to (sub)domains of the

business? What are the

relationships between the teams responsible for

them?

This is where we can vastly expand our horizons

Event storming

Interviewing domain experts

Crunch domain knowledge

Grow a model

Refine a model

Make it do useful work

“software that matters”

agile

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

About BDD

behavior-driven development

Dan North

I want…

Okay

stakeholder programmer

Agile!

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

heuristic

As a … I want to … So that …

user story

Given … When … Then …

Given … When … Then …

Given … When … Then …

scenarios, examples, acceptance criteria

Given … When … Then …

Make executable

–Dan North

“BDD is about implementing an application by describing its

behavior from the perspective of its stakeholders”

Write a failing acceptance test

Write a failing unit test

Make the test pass

BDD is an agile methodology for creating software that matters

Ubiquitous language

Expected behavior

Requirements analysis

Domain experts

Acceptance criteria

just like with DDD!

Testing and the tools are only of “secondary” interest

but great nonetheless!

Modelling by Example

Konstantin Kudryashov

Design your domain model guided by examples

Domain

Application

Infrastructure

database

UI

HTTP

filesystem

Test your scenario’s against the application or domain layer

Domain

Application

Run some scenario’s against the infrastructure layer

Domain

Application

Infrastructure

Unit

Acceptance

UICiaran McNulty

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

About CQRS and Event Sourcing

First: what’s CQS

command query separation

Bertrand Meyer

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

command function

query function

Second: what’s CQRS

command query responsibility segregation

Greg Young

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

Entity

ReadModel

Database

“CQRS lite”

Entity

ReadModel

Database

Database

?

Domain events!

just like with DDD (again)

Entity

Domain event

ReadModel External serviceReadModel

projection

tailor-made for a particular view

Entity created

Information changed

Some other event

Yet another event

Event store

Domain event

Report AnalyticsNew read model

add new subscribers at any time

Visualise event streams

Jef Claes

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…

About Microservices

Sam Newman

Something known as a monolith

Micro-service

Micro-service

Micro-service

Micro-service

Micro-service

better!

Micro-service

Micro-service

Micro-service

Micro-service

Micro-service

Micro-service

Command

Event

Command

Event

loose coupling (dependency inversion)

Micro-service

Storage

Decentralized data

Micro-service

Service-oriented

Command

Query

Micro-service

Event

Event-driven

Micro-service

Ideally mapped to Bounded Contexts

Yes… DDD!

Micro-serviceMicro-service

Replaceable

Micro-service

Different technologies

Micro-service

Micro-service

Microservices done right:

Resilient Redundant

Separately deployable Decoupled

Need a lot of:

Monitoring Automation

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

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

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?

It turns out… you are the cool kids

You know more than you think You do special things

You’re beautiful

Share what you do

interesting!wow!

aha!

Push yourself to the limit

Learn about the cool stuff that’s here to stay

DDD BDD

Microservices

CQRS/ES

Hexagonal

Abstract the fashionable details

Thank you!

legacy.joind.in/16397

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)