Domain-Driven Design in PHP

Slide 1

Slide 1 text

Once upon the time, in ancient Greece...

Slide 2

Slide 2 text

Hercules got into to serious troubles...

Slide 3

Slide 3 text

King Eurystheus ordered Hercules to clean up Augeas' stables

Slide 4

Slide 4 text

The stables was complex and full of mud

Slide 5

Slide 5 text

As accounted for real hero, Hercules used nifty trick

Slide 6

Slide 6 text

He changed flow of a river and directed it into two holes in opposite walls

Slide 7

Slide 7 text

The task has been solved in a single day

Slide 8

Slide 8 text

Unfortunately there’s no such heroic attempts in history of software development

Slide 9

Slide 9 text

Instead of heroes, you need ...

Slide 10

Slide 10 text

Domain-Driven Design in PHP Wojciech Sznapka PHPCon 2014

Slide 11

Slide 11 text

Hi! I'm Wojciech Sznapka * Head Of Development @ Cherry Poland * Coding since 10 years * Interested in architecture, Big Data, Ice Hockey

Slide 12

Slide 12 text

DDD essentials

Slide 13

Slide 13 text

Domain-Driven Design is a way of developing complex software ...

Slide 14

Slide 14 text

... by focusing on core domain first ...

Slide 15

Slide 15 text

... modeling and abstracting reality using “building blocks” and proven design patterns ...

Slide 16

Slide 16 text

and delaying technical decisions as much as possible.

Slide 17

Slide 17 text

It’s all about the domain

Slide 18

Slide 18 text

You can’t build properly working software without deep domain knowledge

Slide 19

Slide 19 text

But, you won’t understand the whole domain at once. It's an iterative process

Slide 20

Slide 20 text

You need evolving model

Slide 21

Slide 21 text

It’s crucial to have common understanding from day one...

Slide 22

Slide 22 text

… and to speak Ubiquitous Language with stakeholders and Domain Experts

Slide 23

Slide 23 text

The model

Slide 24

Slide 24 text

Good model act as Ubiquitous Language

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

It reflect domain logic as much as possible

Slide 27

Slide 27 text

It's build using layers * User interface * Application layer * Domain layer * Infrastructure layer

Slide 28

Slide 28 text

* source: Domain-Driven Design Quickly by InfoQ

Slide 29

Slide 29 text

User interface presents and interprets user commands

Slide 30

Slide 30 text

Application layer coordinates activities. It's ought to be very thin

Slide 31

Slide 31 text

Domain layer is the heart of the system, responsible for business logic

Slide 32

Slide 32 text

Infrastructure layer acts as support, providing persistence, tools, etc.

Slide 33

Slide 33 text

Let’s speak about entities, DDD first class citizens

Slide 34

Slide 34 text

Entity represents a business being

Slide 35

Slide 35 text

Entity is not a simple Data Transfer Object or data container

Slide 36

Slide 36 text

Therefore avoid anemic entities . Good entity should provide behavior, besides identity and attributes!

Slide 37

Slide 37 text

Infrastructure layer helps with persisting entities (using a backing service* of your choice) * http://12factor.net/backing-services

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

Entities are supported by value objects

Slide 40

Slide 40 text

Value objects conceptually does not provide any identity, so they can be shared

Slide 41

Slide 41 text

To achieve that, value objects need to be immutable* * http://blog.sznapka.pl/immutable-value-objects-in-php

Slide 42

Slide 42 text

The important fact: value objects are type hintable

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Large graph of entities can be difficult to handle consistently

Slide 45

Slide 45 text

DDD introduced a term Aggregate which is collection of objects ...

Slide 46

Slide 46 text

... bound with aggregate root and hiding underlying objects from the external world

Slide 47

Slide 47 text

Aggregates provides a coherent interface to operate on sub-graph of the model

Slide 48

Slide 48 text

During development of ubiquitous language you’ll find that some actions don’t belong to any object

Slide 49

Slide 49 text

Such situations are solved with domain services

Slide 50

Slide 50 text

Services employ various entities, value objects, factories, repositories to do their job

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

When dealing with complex objects, their creation could be complex and it's good to hide that logic

Slide 53

Slide 53 text

Well known factories will do the trick

Slide 54

Slide 54 text

Factory hides instantiation complexity and enables interchangeability in the future

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

While factories help with objects creation, it is equally important to abstract objects retrieval

Slide 57

Slide 57 text

Repository design pattern abstracts objects retrieval from a storage

Slide 58

Slide 58 text

It’s extremely important to place all data access logic in repositories

Slide 59

Slide 59 text

Infrastructure layer helps a lot here

Slide 60

Slide 60 text

It uses your ORM library to build specific queries or use other vendors to obtain objects

Slide 61

Slide 61 text

More important fact is that repository* is replaceable * like the most of DDD building blocks

Slide 62

Slide 62 text

Model boundaries

Slide 63

Slide 63 text

It’s important to draw bold borders inside your system, as it grows and becomes complex

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

When different stakeholders start to confuse you with vocabulary

Slide 68

Slide 68 text

It's good time to think about bounded contexts

Slide 69

Slide 69 text

“Bounded Context is a central pattern in Domain-Driven Design”* * http://martinfowler.com/bliki/BoundedContext.html

Slide 70

Slide 70 text

It’s quite sure, that bounded contexts will share common concepts

Slide 71

Slide 71 text

Therefore create context map to outline points of contact between them

Slide 72

Slide 72 text

Also, distinguish core domain from generic ones...

Slide 73

Slide 73 text

Choose proper bounded context collaboration model

Slide 74

Slide 74 text

Shared kernel, when two teams work closely on subset of domain

Slide 75

Slide 75 text

They acts as partners, and access each other bounded context with common code

Slide 76

Slide 76 text

Customer-Supplier, when upstream team provides an API and downstream teams consume it

Slide 77

Slide 77 text

Customer team can influence Supplier to modify model

Slide 78

Slide 78 text

Open Host Service, when interface is defined by widely known protocol

Slide 79

Slide 79 text

It's typical SOA approach

Slide 80

Slide 80 text

Or: * Partner * Conformist * Separate ways * Anticorruption layer * Published language

Slide 81

Slide 81 text

Taming the beast A.K.A. Summary

Slide 82

Slide 82 text

OOP is not enough

Slide 83

Slide 83 text

DDD is great for complex problems

Slide 84

Slide 84 text

You can pick parts of DDD and still benefit out of it

Slide 85

Slide 85 text

You should be aware of duplication and complex structures in DDD

Slide 86

Slide 86 text

DDD doesn't care about your fancy: Symfony/Zend Framework/Laravel * * delete where inapplicable

Slide 87

Slide 87 text

Be PRAGMATIC! * * take care about your core domain in the first place

Slide 88

Slide 88 text

Thanks for your attention! Ask me anything blog.sznapka.pl [email protected] twitter.com/sznapka

Slide 89

Slide 89 text

Your feedback is important! https://joind.in/11844