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
   

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

   View Slide

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
   

   View Slide

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
    

    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 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!
    

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

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    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 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

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.
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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!
    

    View Slide

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
    

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

    View Slide

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
    

    View Slide

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 !
    

    View Slide

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

    View Slide