DDD in PHP

Develop applications become even more challenging in ever growing business requirement and complexities. Domain Driven Design (DDD) offers rigid structure and simplicity in managing domain logic. As the result, DDD serves as basis, enable more sophisticated concepts that we can apply at later stage of the project.

Presentation delivered in PHP User Group Thailand - June 14, 2017

Transcript

1. DDD in PHP Tee Tanawatanakul
2. Agenda - Why Domain Driven Design? - Knowledge Distillation - Models - Factory - Repository - Value Object - Entity - Service - Aggregate & Bounded Context - Domain Events - Derivative Architectures
3. DDD in PHP
4. Why Domain Driven Design?
6. S <- O <- L <- I <- D G -> R -> A -> S -> P S <- O <- A M -> V -> C
7. SOLID, GRASP, And Other Basic Principles of Object Oriented Design https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o
9. Knowledge Distillation
10. 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
11. 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
12. *garble garble garble* The Avenges cast play Chinese Whispers (sorry, "Telephone") on Jimmy Kimmel Live http://imgur.com/gallery/Qoo2I
13. Business -> Analyst -> Developer = No Feedback
15. Business Features -> Developer = No Abstracts
16. Business Domain <-> Developer = Conceptual Contour and that requires repeated refactoring
17. Models
18. Disclaimer All examples are oversimplified for the sake of understanding
19. ✔ ✔ ✔ ✔ ✔ ✔
20. 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
21. 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
22. Value Object - When you care only about attributes - No identity - Equality by value - Conceptual whole - Favor “immutable” object ◦ Is sharable (Flyweight) ◦ Avoid invariant violation
23. 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
24. Service Operations those are not natural to model as entity or value objects - Is “stateless” - Is “side effect free” - Prefer “Closure of Operation”
26. 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
27. 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
28. 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
29. 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
33. Dee Dee Dee.. - Factory - Repository - Value Object - Entity - Service - Aggregate - Bounded Context - Domain Event
35. https://vaughnvernon.co/?p=879
36. 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
37. 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
40. Use Eventual Consistency outside the boundary. Vaughn Vernon
42. Domain Event Something happened that we care about - Vaughn Vernon So if you don’t care “don’t write events in advance” - Me
43. 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”
44. qw3rtman/git-fire https://github.com/qw3rtman/git-fire
45. About HTML5 WebSocket https://www.websocket.org/aboutwebsocket.html
46. ReportingDatabase https://martinfowler.com/bliki/ReportingDatabase.html
47. Domain Event https://martinfowler.com/eaaDev/DomainEvent.html
48. MDA
49. DDDD
50. CQRS +/- ES
51. THANK YOU!