goddd whyyy

As a ddd practitioner who's kind of new in golang I immediately felt the itch to bring the practice within the gophers' realm, and here's the story of the first part of that journey :)

Some links:

* Domain-Driven Design Distilled: https://www.amazon.it/gp/product/0134434420/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=omissis09-21&creative=21718&linkCode=as2&creativeASIN=0134434420&linkId=08c3212a03882953d87f5ee17460acff
* DDD in PHP: https://leanpub.com/ddd-in-php
* Introducing Event Storming: https://leanpub.com/introducing_eventstorming
* DDD Concepts As One Liners: https://blog.sapiensworks.com/post/2015/05/25/DDD-Concepts-As-One-Liners
* Ben Johnson`s Standard Package Layout: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1

Code Repository: https://gitlab.com/omissis/eventstorming-go

Transcript

1. 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
2. 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
3. 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.
4. 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
5. 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
6. ë 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
7. 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
8. 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?
9. 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?
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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!
19. 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
20. 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
21. 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
22. 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
23. ë- 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
24. 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
25. 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
26. 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.
27. 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
28. 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
29. 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.
30. 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
31. 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.
32. 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
33. 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!
34. 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!
35. 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
36. 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 !
37. 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
38. 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 !
39. C O N T A C T S ë twitter: @omissis ë linkedin: claudiobeatrice ë site: tenwarp.com