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
2. Introduction to the Domain-Driven Design tactical patterns with outside-in Test-Driven Development Pim Smeets, João Rosa @p_smeets @joaoasrosa
3. 3 @p_smeets @joaoasrosa • Who are we? • Why this webinar • What we want to do today
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
5. 5 Our domain Domain objects: • Entity • Value Object • Aggregate • Domain Service • Repository
6. 6 @p_smeets @joaoasrosa Getting started with Code Probing
7. 7 Scenario - Example Mapping
8. 8 Model
9. 9 Code Probe Domain objects: • Entity • Value Object • Aggregate • Domain Service • Repository
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?
11. 11 @p_smeets @joaoasrosa Live coding
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
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
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
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