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
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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?
   

   View Slide

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?
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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 !
    

    View Slide

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
    

    View Slide

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 !
    

    View Slide

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

    View Slide