goddd whyyy 1.1

Update of my "goddd whyyy" deck, containing some new "aphorisms" I have put together during the last months.

Original description:

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 v1.1 TUR B O
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? And how to make all that complex stuff work with a tool that is striving for simplicity like Go?
9. 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
10. 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
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 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!
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 - Root package is for core domain types - Group subpackages by dependency - Use a shared mock subpackage - Main package ties together dependencies
15. 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.
16. 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.
17. 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
18. 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
19. 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
20. 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
21. ë- 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
22. 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
23. 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
24. 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.
25. 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
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 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
27. 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.
28. 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
29. 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.
30. 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
31. 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!
32. 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!
33. 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
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 ë TIME TO CODE !
35. 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
36. 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 !
37. C O N T A C T S ë twitter: @omissis ë linkedin: claudiobeatrice ë site: tenwarp.com