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

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

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

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

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

6 @p_smeets @joaoasrosa Getting started with Code Probing

7 Scenario - Example Mapping

8 Model

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

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?

11 @p_smeets @joaoasrosa Live coding

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

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

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

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