DDD for beginners - Speaker Deck

Slide 1

Slide 1 text

DDD for Beginners Rob Allen @akrabat ~ January 2017 ~ http://akrabat.com (slides at http://akrabat.com/talks)

Slide 2

Slide 2 text

The business logic is the hard part Rob Allen ~ @akrabat

Slide 3

Slide 3 text

MVC Rob Allen ~ @akrabat

Slide 4

Slide 4 text

MVC Rob Allen ~ @akrabat

Slide 5

Slide 5 text

DDD is an approach to help you manage the model Rob Allen ~ @akrabat

Slide 6

Slide 6 text

Domain Driven Design A set of patterns for the model: • Language • Strategy • Tactical Rob Allen ~ @akrabat

Slide 7

Slide 7 text

Domain The domain is the "real-world" subject of the project The model is an abstraction of the domain We communicate the model using: • diagrams • use-cases • specifications • etc. Rob Allen ~ @akrabat

Slide 8

Slide 8 text

Is DDD the right choice? DDD requires time, effort and collaboration with the business experts. Benefits: • Useful model of the problem domain • Collaboration between the business & the software teams • Better user experiences with the software • Better architecture through better understanding Rob Allen ~ @akrabat

Slide 9

Slide 9 text

"We have really everything in common with America nowadays except, of course, language" Oscar Wilde Rob Allen ~ @akrabat

Slide 10

Slide 10 text

Ubiquitous Language • A common language between the developers and the business • Limited to how the domain problem • Describes how business itself thinks and operates • Ensures that the team are all on the same page The UL is the agreed concepts, meanings and terms for the project. Rob Allen ~ @akrabat

Slide 11

Slide 11 text

Creating the Ubiquitous Language Conversations in the team exploring how the business operates. • Identify the business processes • Find the inputs and outputs • Document it all! pictures, use-cases, glossary, workflow diagrams, etc. Rob Allen ~ @akrabat

Slide 12

Slide 12 text

Bounded Contexts & Context Maps The context where our UL is valid is called the Bounded Context Insurance example: • Quotation • Policies • Underwriting • Billing • Customer management Rob Allen ~ @akrabat

Slide 13

Slide 13 text

Putting it into practice Rob Allen ~ @akrabat

Slide 14

Slide 14 text

What's in the model? Rob Allen ~ @akrabat

Slide 15

Slide 15 text

Organising the model Rob Allen ~ @akrabat

Slide 16

Slide 16 text

A problem A customer wants to plan a journey between two stations. Rob Allen ~ @akrabat

Slide 17

Slide 17 text

How do we model this? Rob Allen ~ @akrabat

Slide 18

Slide 18 text

Identify the key objects • Customer • Journey • Station • Line Rob Allen ~ @akrabat

Slide 19

Slide 19 text

Identify the relationships Rob Allen ~ @akrabat

Slide 20

Slide 20 text

Entities represent things in the problem-space Rob Allen ~ @akrabat

Slide 21

Slide 21 text

Entity • Means something to the customer • An object defined primarily by its identity • Mutable • Persisted • Has a life cycle Rob Allen ~ @akrabat

Slide 22

Slide 22 text

Identity • The identity of an object is what it means to the customer • Unique within the scope of the domain For a tube station, this is as much its name, as its database ID. My customer is never going to talk to me about station 43, they are going to say "Euston Square". Rob Allen ~ @akrabat

Slide 23

Slide 23 text

Value objects • Defined primarily by its attributes • Immutable • Simple! • Do not exist without an entity Rob Allen ~ @akrabat

Slide 24

Slide 24 text

Entity vs Value Object “ When people exchange dollar bills, they generally do not distinguish between each unique bill; they only are concerned about the face value of the dollar bill. In this context, dollar bills are value objects. However, the Federal Reserve may be concerned about each unique bill; in this context each bill would be an entity.” Wikipedia Rob Allen ~ @akrabat

Slide 25

Slide 25 text

Aggregates A group of Entities and Value objects that need to be consistent when persisted. Example: • Order • Line item Rob Allen ~ @akrabat

Slide 26

Slide 26 text

A station has a location Rob Allen ~ @akrabat

Slide 27

Slide 27 text

A station has a location Rob Allen ~ @akrabat

Slide 28

Slide 28 text

Domain services If a SERVICE were devised to make appropriate debits and credits for a funds transfer, that capability would belong in the domain layer. Eric Evans Rob Allen ~ @akrabat

Slide 29

Slide 29 text

Domain services • We map the business processes to services • Represents behaviour in the domain • A service does not have internal state • Usually a point of connection for many objects Rob Allen ~ @akrabat

Slide 30

Slide 30 text

Domain services Conditions for using a domain service: • Calculations requiring input from multiple domain objects • Performing a significant business process • Transforming a domain object from one composition to another Rob Allen ~ @akrabat

Slide 31

Slide 31 text

Let's look at some code Rob Allen ~ @akrabat

Slide 32

Slide 32 text

An entity 1 class Journey { 2 function getStart() {} 3 function setStart(Station $start) {} 4 5 function getStop() {} 6 function setStop(Station $stop) {} 7 8 function getRoute() {} 9 function setRoute(Route $route) {} 10 } Rob Allen ~ @akrabat

Slide 33

Slide 33 text

A service 1 class RoutingService { 2 pubic function calculateRoute(Station $from, Station $to) : Route {} 3 } Rob Allen ~ @akrabat

Slide 34

Slide 34 text

Anaemic domain model When you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Instead there are a set of service objects which capture all the domain logic. Martin Fowler Rob Allen ~ @akrabat

Slide 35

Slide 35 text

Entity with behaviour 1 class Journey { 2 public function __construct (Station $from, Station $to) {} 3 4 public function calculateRoute() : Route {} 5 } Rob Allen ~ @akrabat

Slide 36

Slide 36 text

What happens if calculateRoute() is complex? Rob Allen ~ @akrabat

Slide 37

Slide 37 text

Implement as a helper The entity calls the helper, passing a reference to itself. 1 // Helper class 2 class JourneyRouter { 3 public function calculateRoute(Journey $journey) : Route {} 4 } 5 6 // Journey class 7 class Journey { 8 function calculateRoute() : Route { 9 $route = $this->journeyRouter->calculateRoute($this); 10 } 11 } Rob Allen ~ @akrabat

Slide 38

Slide 38 text

Persistence Rob Allen ~ @akrabat

Slide 39

Slide 39 text

Persistence options A simple domain model can use TDG or Data Mapper; a complex one will require Data Mapper or an ORM. Aggregates need an ORM Pick the right one! Rob Allen ~ @akrabat

Slide 40

Slide 40 text

But don't use ActiveRecord pattern! Rob Allen ~ @akrabat

Slide 41

Slide 41 text

But don't use ActiveRecord pattern! It integrates the database code into your domain model Rob Allen ~ @akrabat

Slide 42

Slide 42 text

Table Data Gateway • Operates on a single database table • Contains all the SQL for accessing the table • Doesn't know anything about the entity • Simple to implement Rob Allen ~ @akrabat

Slide 43

Slide 43 text

Table Data Gateway 1 class JourneyGateway { 2 function __construct($dbAdapter) {} 3 4 function find($id) {} 5 function findForStartingStation($stationId) {} 6 7 function insert(array $data) {} 8 function update($id, array $data) {} 9 } Rob Allen ~ @akrabat

Slide 44

Slide 44 text

Data Mapper • Class to transfer data from objects to the database and back • Entity aware • Isolates the domain model from the database • Not limited to a single table Rob Allen ~ @akrabat

Slide 45

Slide 45 text

Data Mapper 1 class JourneyMapper { 2 function __construct($dsn, $username, $password) {} 3 4 function find($id) : Journey {} 5 function findForStartingStation($stationId) : [Journey] {} 6 7 public function save(Journey $journey) {} 8 } Rob Allen ~ @akrabat

Slide 46

Slide 46 text

Increased scope: ORM Data mapping that works with the object graphs is known as an Object Relational Mapping Must-have for aggregates, but use a pre-written ORM library! Rob Allen ~ @akrabat

Slide 47

Slide 47 text

ORM Persistence layer is more complicated: • Storage of entire object graphs to the database • Identity map to hold loaded objects • Unit of Work to track changed objects for saving Rob Allen ~ @akrabat

Slide 48

Slide 48 text

Repositories • 1-1 relationship between repository and aggregate • Manage the loading and storing of aggregates • Often oriented around collections of aggregates Rob Allen ~ @akrabat

Slide 49

Slide 49 text

Web services • The persistence storage could be a web service • Data mappers work really well Rob Allen ~ @akrabat

Slide 50

Slide 50 text

Integrating our model into the application Rob Allen ~ @akrabat

Slide 51

Slide 51 text

The application layer* It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. Eric Evans * (Known as service layer in PoEAA) Rob Allen ~ @akrabat

Slide 52

Slide 52 text

Application layer We can sub-divide: • Application services • Infrastructural services Rob Allen ~ @akrabat

Slide 53

Slide 53 text

Application services If the banking application can convert and export our transactions into a spreadsheet file for us to analyze, this is an application SERVICE. Eric Evans Rob Allen ~ @akrabat

Slide 54

Slide 54 text

Application service 1 class JourneyCreator { 2 public function createJourney(Customer $customer, Station $from, Station $t 3 { 4 $journey = $customer->createJourney($from, $to); 5 $journey->calculateRoute(); 6 7 $this->notifier->send($journey); 8 $this->auditor->log("Journey created", $journey); 9 } 10 } Rob Allen ~ @akrabat

Slide 55

Slide 55 text

Beware the Fat service Decouple using Observer pattern Rob Allen ~ @akrabat

Slide 56

Slide 56 text

Infrastructural services A bank might have an application that sends out an email to a customer when an account balance falls below a specific threshold. The interface that encapsulates the email system, and perhaps alternate means of notification, is a SERVICE in the infrastructure layer. Eric Evans Rob Allen ~ @akrabat

Slide 57

Slide 57 text

Infrastructural service • Standard: there's no business or application logic • Reusable across applications • Do not write your own - this is what the ecosystem is for Rob Allen ~ @akrabat

Slide 58

Slide 58 text

To sum up Rob Allen ~ @akrabat

Slide 59

Slide 59 text

To sum up Ubiquitous Language: Agreed vocabulary with the business Bounded Context: Area of the problem space where the Ubiquitous Language is valid Rob Allen ~ @akrabat

Slide 60

Slide 60 text

To sum up Entity: Object with identity that do stuff Value object: Immutable with no identity Domain service: Behaviours that don't belong to an entity Rob Allen ~ @akrabat

Slide 61

Slide 61 text

To sum up Mappers / Repository: Transfer your model to and from persistence Application services: Isolate your domain model from your controllers Infrastructure services: Support services for your application Rob Allen ~ @akrabat

Slide 62

Slide 62 text

Final point Rob Allen ~ @akrabat

Slide 63

Slide 63 text

The success of a design is not necessarily marked by its longevity. It is the nature of software to change. Eric Evans Rob Allen ~ @akrabat

Slide 64

Slide 64 text

Thank you! Please rate this talk on EventsXD Rob Allen ~ @akrabat ~ akrabat.com