Creating Models

I "think" I really got a lot out of this. Thank you. I put think in quotes because I'm just beginning to use classes and the things you present really make sense. I have some good books on design patterns and I really just need to get out there and try stuff out. I will likely make lots of mistakes so I just need to dive in and not get hamstrung on trying to get everything perfect on the first go.

Rob started off by saying his talk was on the introductory level, for newbies to MVC. Every engineer, no matter what the level, can gain some helpful insight onto clean separation of code layers from his talk.
Very well delivered, with helpful examples presented in a easy to understand application process.
Well done.

Will you be posting your presentations here?

These r the parts that I really struggle with. Finally read a great article about this in php architect and this talk provided a great follow-up to that in confirming that the way I am designing my "model" layer now is in line with DDD. Thanks Rob!

Great slides, familiar from the OSCON presentation earlier this year and full of great lessons learned.

I have some thoughts/concerns on this specific take on "double dispatch" however. Not so much that you're using something from inside the model but that I worry about it's usefulness without resorting to coupling & global state.
Any services a model internally instantiates would be isolated from the larger system that predates them. This means that they would really be little more than hideaways for code which could lead to misuse.

I'm not sure if my concerns are exceptions that one has to resign themselves to in order to leverage the pattern -- but I'd love to know a safe pattern for calling services from models without each model having to become the root of a new services graph?

Great talk and intro to DDD. I think you really captured the core essence of it. The only thing I'd change is even more emphasis that as the developer's knowledge of the domain grows, new insights into the true nature of the problem will allow for a better domain model. So to have a better domain model, access to your customers (domain experts) needs to be setup to allow for constant collaboration.

Thanks for the great talk.

great talk. it was a useful informational review even for those familiar with DDD, despite speaker's claim to the contrary.

A lot of information but still presented very clearly. It might be good to have a diagram at the end of the talk showing all the model parts and how they are interacting to give a big picture overview to what we've just learned.