Domain-Driven Design in PHP

Transcript

1. Once upon the time, in ancient Greece...
2. Hercules got into to serious troubles...
3. King Eurystheus ordered Hercules to clean up Augeas' stables
4. The stables was complex and full of mud
5. As accounted for real hero, Hercules used nifty trick
6. He changed flow of a river and directed it into two holes in opposite walls
7. The task has been solved in a single day
8. Unfortunately there’s no such heroic attempts in history of software development
9. Instead of heroes, you need ...
10. Domain-Driven Design in PHP Wojciech Sznapka PHPCon 2014
11. Hi! I'm Wojciech Sznapka * Head Of Development @ Cherry Poland * Coding since 10 years * Interested in architecture, Big Data, Ice Hockey
12. DDD essentials
13. Domain-Driven Design is a way of developing complex software ...
14. ... by focusing on core domain first ...
15. ... modeling and abstracting reality using “building blocks” and proven design patterns ...
16. and delaying technical decisions as much as possible.
17. It’s all about the domain
18. You can’t build properly working software without deep domain knowledge
19. But, you won’t understand the whole domain at once. It's an iterative process
20. You need evolving model
21. It’s crucial to have common understanding from day one...
22. … and to speak Ubiquitous Language with stakeholders and Domain Experts
23. The model
24. Good model act as Ubiquitous Language
26. It reflect domain logic as much as possible
27. It's build using layers * User interface * Application layer * Domain layer * Infrastructure layer
28. * source: Domain-Driven Design Quickly by InfoQ
29. User interface presents and interprets user commands
30. Application layer coordinates activities. It's ought to be very thin
31. Domain layer is the heart of the system, responsible for business logic
32. Infrastructure layer acts as support, providing persistence, tools, etc.
33. Let’s speak about entities, DDD first class citizens
34. Entity represents a business being
35. Entity is not a simple Data Transfer Object or data container
36. Therefore avoid anemic entities . Good entity should provide behavior, besides identity and attributes!
37. Infrastructure layer helps with persisting entities (using a backing service* of your choice) * http://12factor.net/backing-services
39. Entities are supported by value objects
40. Value objects conceptually does not provide any identity, so they can be shared
41. To achieve that, value objects need to be immutable* * http://blog.sznapka.pl/immutable-value-objects-in-php
42. The important fact: value objects are type hintable
44. Large graph of entities can be difficult to handle consistently
45. DDD introduced a term Aggregate which is collection of objects ...
46. ... bound with aggregate root and hiding underlying objects from the external world
47. Aggregates provides a coherent interface to operate on sub-graph of the model
48. During development of ubiquitous language you’ll find that some actions don’t belong to any object
49. Such situations are solved with domain services
50. Services employ various entities, value objects, factories, repositories to do their job
52. When dealing with complex objects, their creation could be complex and it's good to hide that logic
53. Well known factories will do the trick
54. Factory hides instantiation complexity and enables interchangeability in the future
56. While factories help with objects creation, it is equally important to abstract objects retrieval
57. Repository design pattern abstracts objects retrieval from a storage
58. It’s extremely important to place all data access logic in repositories
59. Infrastructure layer helps a lot here
60. It uses your ORM library to build specific queries or use other vendors to obtain objects
61. More important fact is that repository* is replaceable * like the most of DDD building blocks
62. Model boundaries
63. It’s important to draw bold borders inside your system, as it grows and becomes complex
67. When different stakeholders start to confuse you with vocabulary
68. It's good time to think about bounded contexts
69. “Bounded Context is a central pattern in Domain-Driven Design”* * http://martinfowler.com/bliki/BoundedContext.html
70. It’s quite sure, that bounded contexts will share common concepts
71. Therefore create context map to outline points of contact between them
72. Also, distinguish core domain from generic ones...
73. Choose proper bounded context collaboration model
74. Shared kernel, when two teams work closely on subset of domain
75. They acts as partners, and access each other bounded context with common code
76. Customer-Supplier, when upstream team provides an API and downstream teams consume it
77. Customer team can influence Supplier to modify model
78. Open Host Service, when interface is defined by widely known protocol
79. It's typical SOA approach
80. Or: * Partner * Conformist * Separate ways * Anticorruption layer * Published language
81. Taming the beast A.K.A. Summary
82. OOP is not enough
83. DDD is great for complex problems
84. You can pick parts of DDD and still benefit out of it
85. You should be aware of duplication and complex structures in DDD
86. DDD doesn't care about your fancy: Symfony/Zend Framework/Laravel * * delete where inapplicable
87. Be PRAGMATIC! * * take care about your core domain in the first place
88. Thanks for your attention! Ask me anything blog.sznapka.pl wojciech@sznapka.pl twitter.com/sznapka
89. Your feedback is important! https://joind.in/11844