goddd whyyy 1.1 - 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 v1.1 TUR B O

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? And how to make all that complex stuff work with a tool that is striving for simplicity like Go?

Slide 9

Slide 9 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 10

Slide 10 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 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 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 A few options: -The Monolith: all in one pkg - Go on Rails: controller, model pkgs - Group by module: user, product pkgs - DDD Monkey: infra, app, domain pkgs There`s a better way!

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 - Root package is for core domain types - Group subpackages by dependency - Use a shared mock subpackage - Main package ties together dependencies

Slide 15

Slide 15 text

T H E T I M E F O R W I S D O M E V E R Y B O D Y L I K E S S O M E A P H O R I S M S - wrap infra packages so that they don't leak out of our own infra packages. - between subfolders hell and a long file list hell, prefer the second. - find a reasonable comment format to separate the sections of the file.

Slide 16

Slide 16 text

T H E T I M E F O R W I S D O M E V E R Y B O D Y L I K E S S O M E A P H O R I S M S - prefer to group symbols by meaning rather than by type. - in domain, let domain concepts drive the structure. - in infrastructure, let the infrastructural ones lead instead.

Slide 17

Slide 17 text

T H E T I M E F O R W I S D O M E V E R Y B O D Y L I K E S S O M E A P H O R I S M S - when the package becomes too crowded, you can resort to method receivers (as opposed to plain functions) to reduce symbols pollution

Slide 18

Slide 18 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 19

Slide 19 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 20

Slide 20 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 21

Slide 21 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 22

Slide 22 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 23

Slide 23 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 24

Slide 24 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 25

Slide 25 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 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 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 27

Slide 27 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 28

Slide 28 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 29

Slide 29 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 30

Slide 30 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 31

Slide 31 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 32

Slide 32 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 33

Slide 33 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 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 ë TIME TO CODE !

Slide 35

Slide 35 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 36

Slide 36 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 37

Slide 37 text

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