Why DDD Matters Today - Speaker Deck

Slide 1

Slide 1 text

Why DDD Matters Today @ziobrando

Slide 2

Slide 2 text

What is software development?

Slide 3

Slide 3 text

“Writing software is like building a house” Idea N° 1

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

#protip: they’re not *really* building a house

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

“We are translating requirements into working software” Idea N° 2

Slide 8

Slide 8 text

The benevolent wisdom of the domain expert Our eternal Gratitude

Slide 9

Slide 9 text

The shape of the organization

Slide 10

Slide 10 text

Just add a translator here…

Slide 11

Slide 11 text

The knowledge distribution

Slide 12

Slide 12 text

“It's a basic truth of the human condition that everybody lies. The only variable is about what.” Dr. Gregory House

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

Enterprise software development is discovery, challenge, and investigation

Slide 15

Slide 15 text

“Software development is a learning process Working code is a side effect”

Slide 16

Slide 16 text

Not all software development is the same “Core domain”

Slide 17

Slide 17 text

https://www.spreadshirt.de/selbst- gestalten? product=169608967&view=1#? af fi liateId=1246955&orgn=CYO&net w=LI

Slide 18

Slide 18 text

Delivery without understanding Pretty dumb idea Dominant pattern in enterprise software development

Slide 19

Slide 19 text

In the Core Domain, LEARNING is the key asset

Slide 20

Slide 20 text

Strategies for non-core Traditional On-Time / On-Budget Pseudo-Agile thing Follow the backlog Avoid Taking unnecessary risks No time for “gold plating”

Slide 21

Slide 21 text

Standard Approaches Won’t deliver in the CORE

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Strategies for CORE Creative collaboration with domain experts Experiments Continuous refinement of knowledge AND implementation

Slide 24

Slide 24 text

There is no such thing as “Gold Plating” in the Core Domain

Slide 25

Slide 25 text

It’s “Gold Making” in the core

Slide 26

Slide 26 text

DDD is for domains that can’t be modelled right in one shot

Slide 27

Slide 27 text

1) Too complex to be understood without experimenting

Slide 28

Slide 28 text

2) Continuously Evolving

Slide 29

Slide 29 text

“Chasing the right model” AKA “Creative collaboration”

Slide 30

Slide 30 text

The business problem Our understanding Our implementation

Slide 31

Slide 31 text

If you can keep the three close…

Slide 32

Slide 32 text

The business problem

Slide 33

Slide 33 text

Easy!

Slide 34

Slide 34 text

1) Understand the problem

Slide 35

Slide 35 text

What happens when you google “software developer” for images?

Slide 36

Slide 36 text

clueless dude in the middle Slacking off gears? Watching porn My man! xactly!!

Slide 37

Slide 37 text

Software development is a learning process

Slide 38

Slide 38 text

But we’re always doing “second hand” learning

Slide 39

Slide 39 text

2) Keep the implementation as close as possible to our understanding #protip this is what Ubiquitous Language is all about

Slide 40

Slide 40 text

…of course we do!

Slide 41

Slide 41 text

Nobody writes bad software intentionally … or so we think!

Slide 42

Slide 42 text

We are just trying to do a good job!

Slide 43

Slide 43 text

The Cracks in the Monolith Making sense of a huge mess

Slide 44

Slide 44 text

“Every piece of knowledge must have a single, unambiguous, authoritative representation, within a system” Andy Hunt & Dave Thomas The DRY principle

Slide 45

Slide 45 text

“Every piece of knowledge must have a single, unambiguous, authoritative representation, within a system” Andy Hunt & Dave Thomas The DRY principle

Slide 46

Slide 46 text

Modelling Data-First Focus on nouns Expand the scope in order to accomodate new concepts … … Leave the company cursing the Legacy

Slide 47

Slide 47 text

Nouns won’t help Everybody agrees what an order is? Of course we do! An order is an order! And has a customer too! Agreed!

Slide 48

Slide 48 text

Perfect recipe: Talk with many people Model Data-First (everybody agrees on nouns) Add some “Dogmatic DRY principle” Repeat

Slide 49

Slide 49 text

The Big Ball of Mud I swear it was a monolith last time I checked!!!

Slide 50

Slide 50 text

A single model won’t solve an enterprise problem, We’ll need more!

Slide 51

Slide 51 text

Conceptual boundaries

Slide 52

Slide 52 text

Microservices Is Envy a driver for architectural choices?

Slide 53

Slide 53 text

… only to discover that they’re tangled with dependencies!! I spend most of my time rescuing teams that went micro services over a monolith…

Slide 54

Slide 54 text

https://www.dropbox.com/s/zb4imheanczmkc6/ Screenshot%202017-10-20%2000.20.11.png?dl=0

Slide 55

Slide 55 text

How do I untangle this mess?

Slide 56

Slide 56 text

Conceptual boundaries?

Slide 57

Slide 57 text

Bounded Context Is a LANGUAGE boundary. Defines a consistent MODEL around a specific PURPOSE #PROTIP: “Managing” is not a purpose

Slide 58

Slide 58 text

MicroService A DEPLOYMENT boundary: MICRO* means ‘as small as possible’ You are not necessarily Netflix

Slide 59

Slide 59 text

… so…?

Slide 60

Slide 60 text

… “so a Microservice is a bounded Context”

Slide 61

Slide 61 text

You’ve just collapsed two fuzzy concepts into one!!!

Slide 62

Slide 62 text

… Still I have no Idea what a Bounded Context is I have no Idea what a micro service is, but I am pretty sure it’s a bounded Context But I am using Docker!

Slide 63

Slide 63 text

… just being exilicit More microservices within a bounded context Just don’t call it “micro*” anymore.

Slide 64

Slide 64 text

You’re not Netflix!

Slide 65

Slide 65 text

But One thing is clear…

Slide 66

Slide 66 text

This works just better!

Slide 67

Slide 67 text

Domain Events Provide the best abstraction for modelling enterprise software

Slide 68

Slide 68 text

Safety You just won’t learn under pressure

Slide 69

Slide 69 text

Thin red line • Start a project with a data first approach • Add misunderstood DRY PRINCIPLE • Lack of control requires protection & specialisation • few people become key, others retire or get minionized Business grows on top of old code • SAFETY is gone. Without it, no experiments are possible. • More responsibilities: less time to change it, harder to make the call • Hard to recruit seniors to finish the job

Slide 70

Slide 70 text

Thin red line • Postpone evolutions of critical software • prevent the organisation from getting new feedback • -> how long are your iterations? • Suddenly realise that the organisation is dumbed down and blames IT for everything