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

goddd whyyy 1.1

omissis
February 19, 2020

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

omissis

February 19, 2020
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
    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