Imagine, if you will, a world where you're able to define a tailor-made type for domain objects that is always valid, type-safe, immutable, and easy to test. No more email addresses passed around as plain strings, nor associative arrays being passed around with potentially-undefined keys and unpredictable types.

In this session, we'll dive deep into PHP Value Objects: where are they useful, how do we write (and test!) them, and how do we ensure that the data they encapsulate is valid? Attendees will leave with a better understanding of domain modeling, Value Objects, and immutability.

Warning: once you start using proper value objects, you may never be able to go back to using anything else!

Comments

Please login to leave a comment

Adrian Olives at 16:47 on 25 Oct 2024

This was a great talk! Super entertaining and informative.
(Maybe add a Doctrine hydration example slide)

Korvin Szanto at 16:55 on 25 Oct 2024

Great talk with a lot of good examples and clear code

Loved the presentation and the overall flow. It was. Very engaging, and great useful information.

Fantastic talk. I would have liked a bit more variety in the examples but nevertheless it was a very complete talk that covered an amazing amount of ground in 50 minutes. Well done!

Lane Staples at 11:55 on 27 Oct 2024

Steve gave a great introduction to Value Objects, making their benefit and implementation easy to understand. I look forward to adding them to my conceptual toolkit!

Really good information and presentation of use cases for Value Objects. I think the code examples are a little too basic/bespoke, because it was a little tricky for me to visualize a use case for our codebase. Seemed like adding PVO's to our entities would just be adding objects to add objects. Suggestion: Prove me wrong!! Show trickier, more real-world code.

Omni Adams at 17:50 on 28 Oct 2024

Now I'm looking through my codebase for more things to convert to value objects. They seem like a great way to take the type safety of scalar objects one step further. The talk would certainly benefit for more non-age-related examples.