Talk in English - US at Dutch PHP Conference 2018
Short URL: https://joind.in/talk/bd6fd
(QR-Code (opens in new window))
The traditional approach to data modeling is to create a single unified model. We use one User model to represent users in each and every feature. As this relationship graph grows, the data model becomes increasingly difficult to change.
In this session we’ll explore ways to create useful Eloquent data models that are smaller, more focused, and are much easier to change.
This session is for beginning or expert developers of applications large or small.
Comments
Comments are closed.
Sometimes it promoted bad practices
Interesting thoughts on approach of decoupling your models. Never thought of models over barriers through events.
Honestly one of the most approachable talks when it comes to boundaries
Not a bad talk. I've seen much better talks from Shawn, but it was nevertheless a very useful talk with good points
Nice talk.
Interesting take on making models more loosely coupled, but comes with a important down sides that the speaker didn't mention or glossed over. This kind of coupling breaks the 'one source of truth' rule, misconfigured events or outside changes could create invalid data. There is very little preventing (for example) speaker.name and talk.speakerName having different values.
Very interesting approach on how to explain boundaries.
The idea this talk conveys is really important, I had some analysis paralysis regarding the possible approaches to this matter, and this cleared it up nicely.
I felt that this talk is less about "this is how you should do things", but more of a talk to challenge the status quo and lets try something new and different to make things better because the speaker is not happy with how things are in the web dev community. Not a lot of people are out there trying to push the boundaries, but Shawn is one of them.
Great insight in how to prevent a model from exploding for different feature. I think it wouldn't be wise to store everything redundant, but there could be use cases where this might be useful.
Good talk, useful insights into boundaries.
Nice talk, but would have preferred some more content about the tradeoffs involved in your approach, also with regards to testability. Also, I think the message you're trying to get across is easily understood: instead of a gentle introduction to bounded contexts people might have interpreted it as an advice to create a separate datamodel for every (small) feature. That might be something to watch out for.