DDD in PHP - Speaker Deck

Slide 1

Slide 1 text

DDD in PHP Tee Tanawatanakul

Slide 2

Slide 2 text

Agenda - Why Domain Driven Design? - Knowledge Distillation - Models - Factory - Repository - Value Object - Entity - Service - Aggregate & Bounded Context - Domain Events - Derivative Architectures

Slide 3

Slide 3 text

DDD in PHP

Slide 4

Slide 4 text

Why Domain Driven Design?

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

S <- O <- L <- I <- D G -> R -> A -> S -> P S <- O <- A M -> V -> C

Slide 7

Slide 7 text

SOLID, GRASP, And Other Basic Principles of Object Oriented Design https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Knowledge Distillation

Slide 10

Slide 10 text

Design a portion of the software system to “reflect the domain model in a very literal way” Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a robust UBIQUITOUS LANGUAGE. Eric Evans

Slide 11

Slide 11 text

Use model as the backbone of the language. Use the same language in diagrams, writing and especially speech. Recognize that a change in the UBIQUITOUS LANGUAGE is a change to the model Eric Evans

Slide 12

Slide 12 text

*garble garble garble* The Avenges cast play Chinese Whispers (sorry, "Telephone") on Jimmy Kimmel Live http://imgur.com/gallery/Qoo2I

Slide 13

Slide 13 text

Business -> Analyst -> Developer = No Feedback

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

Business Features -> Developer = No Abstracts

Slide 16

Slide 16 text

Business Domain <-> Developer = Conceptual Contour and that requires repeated refactoring

Slide 17

Slide 17 text

Models

Slide 18

Slide 18 text

Disclaimer All examples are oversimplified for the sake of understanding

Slide 19

Slide 19 text

✔ ✔ ✔ ✔ ✔ ✔

Slide 20

Slide 20 text

Creating instances of aggregates and complex objects - Each operation must be atomic - Produces only object in a “consistent state” - Aggregate/Entity: All invariants satisfied, optional elements can be added later. - Value Object: All attributes are initialized to their correct final stats. Factory

Slide 21

Slide 21 text

Provide the illusion of an in-memory collection of all objects of that type - Encapsulating storage and query technology - Provide methods to add, remove, select objects (using intention-revealing interface) - Persistent ignorance = Repository done right! - Specification Based Query - Query Function - Polyglot Persistence Repository

Slide 22

Slide 22 text

Value Object - When you care only about attributes - No identity - Equality by value - Conceptual whole - Favor “immutable” object ○ Is sharable (Flyweight) ○ Avoid invariant violation

Slide 23

Slide 23 text

Entity When object is distinguished by its identity - “...thread of continuity and identity.” - Bob from Wyoming - Bob from Dakota - Unique within the system even though.. - Same descriptive attribute - Distributed - Archived

Slide 24

Slide 24 text

Service Operations those are not natural to model as entity or value objects - Is “stateless” - Is “side effect free” - Prefer “Closure of Operation”

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Layered Architecture - Presentation Layer - Interpret user’s command - External actor might be human/computer - Does not contain business rules - Coordinate and delegate tasks to domain layer - Generic technical capabilities e.g. message sending, drawing widgets to UI, persistence for the domain - Responsible for concepts of business - The “heart” of business software

Slide 27

Slide 27 text

Anemia Domain Model The catch comes 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. - Martin Fowler

Slide 28

Slide 28 text

Anemia Domain Model Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data. - Martin Fowler

Slide 29

Slide 29 text

Anemia Domain Model Sometimes services masquerade as model objects, appearing as objects with no meaning beyond doing some operation. These “doers” end up with name ending in “Manager” and the like - Eric Evans

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

Dee Dee Dee.. - Factory - Repository - Value Object - Entity - Service - Aggregate - Bounded Context - Domain Event

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

https://vaughnvernon.co/?p=879

Slide 36

Slide 36 text

Choose one entity to be to be Aggregate Root Control all access through the root Reference Other Aggregates by Identity https://vaughnvernon.co/?p=879

Slide 37

Slide 37 text

The root entity has global identity and is ultimately responsible for checking invariants Only Aggregate Roots can be obtained directly with database queries. Everything else must be done through traversal Nothing outside the aggregate boundary can hold a reference to anything inside, except to the root entity A delete operation must remove everything within the Aggregate boundary all at once Consistency Boundary

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Use Eventual Consistency outside the boundary. Vaughn Vernon

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

Domain Event Something happened that we care about - Vaughn Vernon So if you don’t care “don’t write events in advance” - Me

Slide 43

Slide 43 text

Domain Event Something happened that we care about - Domain event is immutable - Represent the “fact” -> “interpretation” - Allow Separation of Concern - Leverage “push” model (data delivery) - Enable “asynchronous” web services - Enable (near) “real-time” process - Enable historical analysis / audit log “time-travelling”