goddd whyyy - Speaker Deck

Slide 1

Slide 1 text

G O D D D W H Y Y Y G O D D D W H Y Y Y G O D D D W H Y Y Y G O D D D W H Y Y Y

Slide 2

Slide 2 text

D O M A I N - D R I V E N D E S I G N T A C K L I N G C O M P L E X I T Y I N S O F T W A R E ë- handling complex business domains ë- producing high-quality software

Slide 3

Slide 3 text

G O L A N G S I M P L E I S M O R E ëGo is an open source programming language that makes it easy to build simple, reliable, and efficient software.

Slide 4

Slide 4 text

Even among scientists, there is no unique definition of complexity - Neil Fraser Johnson C O M P L E X I T Y S T A N D B A C K , S C I E N C E I S C O M I N G . . O R N O T

Slide 5

Slide 5 text

Number of WTFs per minute - Randall Munroe C O M P L E X I T Y X K C D A L W A Y S G E T S I T R I G H T

Slide 6

Slide 6 text

ë NPath complexity ë Cyclomatic Complexity ë LOCs T A M I N G C O M P L E X I T Y Y O U S H A L L N O T P A S S Code Rules Test Coverage Static Analysis Code Review CI/CD

Slide 7

Slide 7 text

T H E S I M P L I C I T Y T R A P A S I M P L E G U Y W A L K S I N T O A C O F F E E "simplest": 2 people, π opinions fear of unanticipated change leads to over-engineering fear of over-engineering leads to lack of deep -if any- design thinking

Slide 8

Slide 8 text

T A M I N G C O M P L E X I T Y S I T D O W N , W E O U G H T A T A L K What about, like, the business domain thing we were talking about earlier?

Slide 9

Slide 9 text

T A M I N G C O M P L E X I T Y S I T D O W N , W E O U G H T A T A L K And how to make all that complex stuff work with a tool that is striving for simplicity like Go?

Slide 10

Slide 10 text

vs T W O W O R L D S C O L L I D E T H E Y T O L D M E N A M I N G I S H A R D

Slide 11

Slide 11 text

T W O W O R L D S C O L L I D E O N C E U P O N A M O D U L E

Slide 12

Slide 12 text

T W O W O R L D S C O L L I D E O N C E U P O N A M O D U L E

Slide 13

Slide 13 text

T W O W O R L D S C O L L I D E O N C E U P O N A M O D U L E

Slide 14

Slide 14 text

T H E E P I C Q U E S T F O R T H E T R U E S T R U C T U R E O R H O W I J U S T F O U N D T H E R I G H T B L O G P O S T OPTION 1 : The Monolith PRO: no circular dependencies CON: no modularity, harder to maintain

Slide 15

Slide 15 text

T H E E P I C Q U E S T F O R T H E T R U E S T R U C T U R E C O N T R O L L E R . U S E R C O N T R O L L E R OPTION 2 : Go on Rails PRO: cannot think of any CON: atrocious naming, easy circular dependencies

Slide 16

Slide 16 text

T H E E P I C Q U E S T F O R T H E T R U E S T R U C T U R E U S E R S . U S E R , T A G S . R E P O S I T O R Y OPTION 3 : Group by module PRO: somewhat more cohesive CON: still terrible naming, easy circular dependencies

Slide 17

Slide 17 text

T H E E P I C Q U E S T F O R T H E T R U E S T R U C T U R E T H R E E P A C K A G E S : D O M A I N , A P P , I N F R A OPTION 4 : DDD Monkey PRO: proper layering, no circular dependencies CON: so-so naming, poor modularisation, not idiomatic

Slide 18

Slide 18 text

T H E E P I C Q U E S T F O R T H E T R U E S T R U C T U R E O R H O W I J U S T F O U N D T H E R I G H T B L O G P O S T OPTION 5 : ParaDDDise PRO: good naming, modularisation and layering, no circular dependencies CON: none! IT IS PUAHFECT!

Slide 19

Slide 19 text

T H E E P I C Q U E S T F O R T H E T R U E S T R U C T U R E O R H O W I J U S T F O U N D T H E R I G H T B L O G P O S T - Root package is for domain types - Group subpackages by dependency - Use a shared mock subpackage - Main package ties together dependencies

Slide 20

Slide 20 text

E N T E R D O M A I N - D R I V E N D E S I G N B O R A T R E C O M M E N D S I T , T O O ë- ubiquitous language ë- strategic patterns ë- tactical patterns

Slide 21

Slide 21 text

U B I Q U I T O U S L A N G U A G E ëThe practice of building up a common, rigorous language between developers and users. B O R A T R E C O M M E N D S I T , T O O ë- Martin Fowler

Slide 22

Slide 22 text

U B I Q U I T O U S L A N G U A G E ëDomain experts should object to terms or structures that are awkward or inadequate to convey domain understanding ëDevelopers should watch for ambiguity or inconsistency that will trip up design. B O R A T R E C O M M E N D S I T , T O O ë- Eric Evans

Slide 23

Slide 23 text

ë- ports and adapters ë- value objects ë- entities ë- repositories ë- factories ë ë- application services ë- domain services ë- domain events ë- aggregates T A C T I C A L P A T T E R N S M A S T E R T H E M A L L Y O U W I L L

Slide 24

Slide 24 text

T A C T I C A L P A T T E R N S V A L U E O B J E C T S ëA Value Object is an immutable object representing a (composite) value that has domain significance ëThink of Money, Credits, Temperature

Slide 25

Slide 25 text

T A C T I C A L P A T T E R N S E N T I T I E S ëAn Entity is a business object representing a domain concept with a stable identity throughout changes over time. ëThink of Users, Products, Purchases

Slide 26

Slide 26 text

T A C T I C A L P A T T E R N S A G G R E G A T E S ëAn Aggregate represents a consistency boundary around a domain concept, often represented as an object graph. ëNothing outside the Aggregate boundary can hold a reference to anything inside, except to the root Entity.

Slide 27

Slide 27 text

T A C T I C A L P A T T E R N S A G G R E G A T E R O O T S ëAn Aggregate Root is a part of the aggregate, and it is in charge of enforcing the aggregate consistency, acting as its representative. ëThe root Entity has global identity and is ultimately responsible for checking invariants

Slide 28

Slide 28 text

T A C T I C A L P A T T E R N S A G G R E G A T E R O O T S ëOnly Aggregate Roots can be obtained directly with database queries.õ Everything else must be done through traversal. ëObjects within the Aggregate can hold references to other Aggregate roots

Slide 29

Slide 29 text

T A C T I C A L P A T T E R N S R E P O S I T O R I E S ëA Repository represents a collection of Entities. ëDepending on the implementation, it can also be responsible for persisting and loading aggregates.

Slide 30

Slide 30 text

T A C T I C A L P A T T E R N S D O M A I N S E R V I C E S ëA Domain service is responsible of encapsulating pure domain behaviour that doesn't have its own persisted state and does not belong specifically to any single entity or value object. ëThink of: calculate tax, sign in, create order from cart

Slide 31

Slide 31 text

T A C T I C A L P A T T E R N S A P P L I C A T I O N S E R V I C E S ëApplication Services are the middleware between the outside world and the Domain logic. ëThe purpose of such a mechanism is to transform commands from the outside world into meaningful Domain instructions.

Slide 32

Slide 32 text

T A C T I C A L P A T T E R N S A P P L I C A T I O N S E R V I C E S ëThink about the top-level use cases that your system exposes to the world ë- as a guest, I want to register ë- as a logged user, I want to purchase a product

Slide 33

Slide 33 text

G E T T I N G P R A C T I C A L Y O U A I N ` T G O N N A B E L I E V E I T ëlet`s pick a domain to work with now!

Slide 34

Slide 34 text

A D D D I N G O E X A M P L E M Y G H A D T H I S I S G O I N G T O B E S O M E T A ë quick! grab some post-its!

Slide 35

Slide 35 text

A D D D I N G O E X A M P L E T H E P I C T H A T E X P L A I N S E V E R Y T H I N G

Slide 36

Slide 36 text

A D D D I N G O E X A M P L E M Y G H A D T H I S I S G O I N G T O B E S O M E T A ë TIME TO CODE !

Slide 37

Slide 37 text

C R E D I T S + R E F E R E N C E S Y E A H I D I D N O T I N V E N T A L L O F T H I S ëDomain-Driven Design Distilled ëDDD in PHP ëIntroducing Event Storming ëDDD Concepts As One Liners ëBen Johnson`s Standard Package Layout

Slide 38

Slide 38 text

G A M E O V E R G A M E O V E R G A M E O V E R G A M E O V E R T H A N K Y O U !

Slide 39

Slide 39 text

C O N T A C T S ë twitter: @omissis ë linkedin: claudiobeatrice ë site: tenwarp.com