Upgrade to Pro — share decks privately, control downloads, hide ads and more …

goddd whyyy

omissis
November 21, 2018

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

omissis

November 21, 2018
Tweet

More Decks by omissis

Other Decks in Programming

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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide