All the cool kids....
•
15 recomendaciones•3,508 vistas
The PHP world is spinning quite fast these days. There’s a lot to keep up with. You can’t be an expert in all subjects, so you need a way to find out what’s relevant for you and your team. Which approaches to software development would be useful? Which programming paradigms could help you write better code? And which architectural styles will help your application to survive in this quickly changing world? In this talk I’ll help you answer these questions by taking a bird’s-eye view. I will quickly guide you along some of the most fascinating topics in modern PHP development: DDD, BDD, TDD, hexagonal architecture, CQRS, event sourcing and micro-services. We’ll see how these things are related to each other, and how understanding and applying them can help you improve your software projects in many ways.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (19)
Similar a All the cool kids....
Similar a All the cool kids.... (20)
Más de Matthias Noback
Más de Matthias Noback (20)
Último
Último (20)
All the cool kids....
- 1. Yeah, they're invincible, and she's just in the background And she says: “I wish that I could be like the cool kids.”
- 2. All the cool kids… @matthiasnoback CTO at
- 4. ? ?
- 5. ?
- 8. Conclusion: Use “cool” things when you understand them
- 9. What else is cool? JavaScript?
- 10. ? ? ? ? ?
- 11. Conclusion: Use “cool” things that last
- 12. Not what this talk is about
- 14. These things are “cool” But they aren’t a hype They have a proven track record
- 15. Why do we need to talk about them again?
- 16. Serious psychological impediments “I want to do what they do” “I’m scared” “I’m doing quite well” “You can’t have it all”
- 17. To be honest
- 18. Our projects may be Too simple Too small Too short-lived Too much time-constrained
- 19. Overcoming anxiety You can do it! You’ll get used to it You could do much better There are “light” options
- 20. You just need to: Listen Read Practice
- 21. About DDD domain-driven design Eric Evans
- 23. Entities Locus of change Identifiable Can act as the root of a bigger aggregate
- 24. Value Objects Immutable Describe aspects of an entity
- 25. Aggregates Compositions of Entities and Value Objects Transactional boundary
- 26. Repositories Act as collections of aggregates
- 27. Domain Events Immutable Notification of change inside an entity
- 28. What changes? We don’t design with the database in mind (we design the objects) We don’t calculate change sets anymore (we only touch one aggregate)
- 29. So far, much of DDD is just “better programming”
- 31. Ubiquitous Language The language spoken by both software developers and business people Prevents translations between business and implementation domain language central to DDD
- 32. Core Domain The aspect of the business domain that is distinctive Good software should make a big difference here
- 33. Generic subdomain The software for this can be a standard solution or outsourced
- 34. Bounded Context There is a boundary for domain models The meaning and relevance of concepts ends at the boundary Allows for separate teams to work on a model
- 36. This is so very useful
- 37. Which bounded contexts exist? How do they map to (sub)domains of the business? What are the relationships between the teams responsible for them?
- 38. This is where we can vastly expand our horizons
- 39. Event storming
- 41. Crunch domain knowledge Grow a model Refine a model Make it do useful work “software that matters” agile
- 42. As a software developer you should be cool and be part of this movement
- 46. What’s the next most important thing the system doesn’t do? heuristic
- 47. As a … I want to … So that … user story
- 48. Given … When … Then … Given … When … Then … Given … When … Then … scenarios, examples, acceptance criteria
- 49. Given … When … Then … Make executable
- 50. –Dan North “BDD is about implementing an application by describing its behavior from the perspective of its stakeholders”
- 51. Write a failing acceptance test Write a failing unit test Make the test pass
- 52. BDD is an agile methodology for creating software that matters
- 53. Ubiquitous language Expected behavior Requirements analysis Domain experts Acceptance criteria just like with DDD!
- 54. Testing and the tools are only of “secondary” interest but great nonetheless!
- 56. Design your domain model guided by examples
- 58. Test your scenario’s against the application or domain layer Domain Application
- 59. Run some scenario’s against the infrastructure layer Domain Application Infrastructure
- 61. BDD, modelling by example: cool and very helpful for reaching the goals set by DDD
- 62. About CQRS and Event Sourcing
- 63. First: what’s CQS command query separation Bertrand Meyer
- 64. class Entity { private $information; public function changeInformation($information) { $this->information = $information; } public function getInformation() { return $this->information; } } command function query function
- 65. Second: what’s CQRS command query responsibility segregation Greg Young
- 66. class Entity { private $information; public function changeInformation($information) { $this->information = $information; } } class ReadModel { private $information; public function getInformation() { return $this->information; } } command function query function
- 69. Domain events! just like with DDD (again)
- 70. Entity Domain event ReadModel External serviceReadModel projection tailor-made for a particular view
- 71. Entity created Information changed Some other event Yet another event Event store
- 72. Domain event Report AnalyticsNew read model add new subscribers at any time
- 73. Visualise event streams Jef Claes
- 74. Look into CQRS and ES because: Your “reads” will be more efficient Your reports/statistics/… are very valuable for you/your clients It fits very well with DDD It makes your application ready for the next challenge…
- 76. Something known as a monolith
- 83. Micro- service Ideally mapped to Bounded Contexts Yes… DDD!
- 86. Microservices done right: Resilient Redundant Separately deployable Decoupled Need a lot of: Monitoring Automation
- 87. Most importantly: it should fit within your organisation Cross-functional teams Different ways of cooperation (Context Map) A microservice architecture offers scaling options for your developer team
- 88. Ignore all the jokes on Twitter and look into this cool thing
- 89. The cool kids
- 90. Who are they? The people at company X? Teams who use Y in production? People who have a Google Friday? Companies with picknick tables and fake grass? People with a Raspberry Pi continuous deployment pipeline?
- 91. It turns out… you are the cool kids
- 92. You know more than you think You do special things You’re beautiful
- 93. Share what you do interesting!wow! aha!
- 94. Push yourself to the limit
- 95. Learn about the cool stuff that’s here to stay DDD BDD Microservices CQRS/ES Hexagonal
- 96. Abstract the fashionable details
- 98. Recommended reading Domain Driven Design (Eric Evans) Implementing Domain Driven Design (Vaughn Vernon) Growing Object-Oriented Software Guided by Tests (Steve Freeman & Nat Pryce) Microservices (Sam Newman) Modelling by Example (Konstantin Kudryashov)