In a new post to his blog Tibo Beijen presents a case study about doing Domain Driven Design in an application using Doctrine2 to work with objects and your database.

Nowadays developing web applications usually requires a flexible process due to changing business logic, shifting priorities or new insights. Besides choosing the right methodology this also requires designing the application in such a way that this flexibility can be achieved. [...] In this article I will show how to implement a specific case using Doctrine 2. Full code accompanying this article can be found on GitHub.

He starts by describing the entities (User/TimeSheet/TimeSheetStatusChange) and how they're defined in Doctrine objects. He modifies them to build in some business-level restrictions like "status changes are only allowed in a certain order". He shows that the domain models presented are about more than just working with the database tables. They enforce rules that effect the flow of the application as well.

Bradley Holt has a new post to his blog about a subject he's recently been learning about, Domain-Driven Design, and how immutable value objects could be useful in PHP.

Yesterday I tweeted: Modern object-oriented programming languages need support for immutable Value Objects. #DDD The "DDD" in that tweet stands for Domain-Driven Design. There were several interesting responses to this tweet.

Responses to his tweet included comments from Matthew Weier O'Phinney, Ralph Schindler, Nicolas Berard-Nault and Giorgio Sironi. He notes that, while all of the suggestions are good, they're only half of the issue. They make it immutable when defined but not during execution. Currently PHP lacks this functionality, but something like this could be worked in with the concept of a "final" class.