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

Introduction to the Domain-Driven Design tactical patterns with outside-in Test-Driven Development @ Xebia Academy webinar week 2020

Introduction to the Domain-Driven Design tactical patterns with outside-in Test-Driven Development @ Xebia Academy webinar week 2020

Domain-Driven Design (DDD) is becoming popular within the software engineering industry. However, we have other practices that can be used as well. How does everything fit together? During this webinar we will do a live coding session. We will walk you through an existing codebase, refactor it using outside-in Test-Driven Development (TDD) while applying DDD tactical patterns to express our intention in code. We will end with a few practical tips and tricks that you can start to apply tomorrow.

João Rosa

May 25, 2020
Tweet

More Decks by João Rosa

Other Decks in Programming

Transcript

  1. Introduction to the
    Domain-Driven Design tactical
    patterns
    with outside-in Test-Driven Development
    Pim Smeets, João Rosa
    @p_smeets @joaoasrosa

    View Slide

  2. Introduction to the
    Domain-Driven Design tactical
    patterns
    with outside-in Test-Driven Development
    Pim Smeets, João Rosa
    @p_smeets @joaoasrosa

    View Slide

  3. 3
    @p_smeets @joaoasrosa
    ● Who are we?
    ● Why this webinar
    ● What we want to do today

    View Slide

  4. 4
    @p_smeets @joaoasrosa
    We will show how to:
    - Implement DDD tactical patterns with outside-in
    TDD
    - Make your codebase as explicit as possible
    - Test behaviour, not implementation
    - Change your codebase without breaking tests
    with a live coding session!
    Agenda

    View Slide

  5. 5
    Our domain
    Domain objects:
    ● Entity
    ● Value Object
    ● Aggregate
    ● Domain Service
    ● Repository

    View Slide

  6. 6
    @p_smeets @joaoasrosa
    Getting started with Code
    Probing

    View Slide

  7. 7
    Scenario - Example Mapping

    View Slide

  8. 8
    Model

    View Slide

  9. 9
    Code Probe
    Domain objects:
    ● Entity
    ● Value Object
    ● Aggregate
    ● Domain Service
    ● Repository

    View Slide

  10. 10
    @p_smeets @joaoasrosa
    Live coding
    Existing domain - model partially implemented
    Refactor;
    ● Ensure that we correctly applied our tactical patterns
    ● Remove unused tests
    Extend; adding a new aggregate
    ● Outside-in TDD
    Change; touch existing code
    ● Where to make the change?
    ● How to do it safely?

    View Slide

  11. 11
    @p_smeets @joaoasrosa
    Live coding

    View Slide

  12. 12
    @p_smeets @joaoasrosa
    Entity & Value Objects
    Entity - who?
    ● Identified by its identity rather than attributes
    ● Identity remains fixed throughout lifecycle, attributes may change
    ● Primarily responsible for identity - not behaviour
    Value Object - what?
    ● Used as descriptors for other domain objects
    ● Can only be identified by its characteristics
    ● Identity not required because characteristics only have meaning in a particular context
    ● Immutable; cannot have state changing methods
    ● Primarily responsible for behaviour - not identity

    View Slide

  13. 13
    @p_smeets @joaoasrosa
    Aggregates
    An aggregate:
    ● Protects business invariance by forming a transactional consistency boundary
    ● Favors a single traversal direction, as opposed to bidirectional relationships
    ● Group domain objects so you can refer to the as a single concept
    ● Is written to / read from persistent storage as a whole through a repository; this can lead to
    eventual consistency
    The aggregate root:
    ● Is the gateway into an aggregate
    ● Is always an entity, without a parent entity
    ● Must be referred to be ID instead of object reference

    View Slide

  14. 14
    @p_smeets @joaoasrosa
    Repository
    A repository
    ● Is an intermediate layer between the domain model and the data layer in your infrastructure
    ● Is defined as an interface in your domain
    ● Implemented in your infrastructure
    ● Supplies your domain with the data that it needs to operate

    View Slide

  15. 15
    @p_smeets @joaoasrosa
    Domain Service
    A domain service can:
    ● Encapsulate business policies and processes or
    ● Act as a contract where the implementation relies on the infrastructure
    It:
    ● Acts as a linking pin between multiple entities / aggregates
    ● Is always stateless
    ● Encapsulates UL and concepts that are important to the domain
    ● Often orchestrates multiple entities or domain objects
    You use it when:
    ● The concept exists in the problem domain
    ● Your domain model at least interfaces with the problem

    View Slide