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.

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