Nicolas Bérard-Nault has put together a new post looking at the role that Value Objects play in application development and, more specifically, how they fit in with domain driven design (DDD). He looks to explain the unknown value of Value Objects to developers that might not know how helpful they really can be.

One of the main rules of DDD is that value objects are immutable. This is often not as self-evident as it seems, as many programmers are not even aware of the state they leak and create. Sadly, state is often positively correlated with entropy. Hence, taking steps to contain and to limit state is one of the keys to taming complexity in an application.

He notes that even outside of DDD Value Objects can be quite useful. He gives an example of a "RationalNumber" class with methods for basic things like addition and subtraction. He shows the more traditional mutable version that most developers would start with and uses it in several examples to show its flaws. He finishes up the post with a look at the "more correct" immutable version of the class and a sample call that would result in the correct output of a simple matematical operation.

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.

Federico Cargnelutti has posted the latest article in his "domain-driven design" series using the Zend Framework. This time he focuses on putting some of his ideas into practice.

Some of the Domain-driven design concepts explained in my previous posts are applied in this sample application. I'm also going to use the Zend Framework infrastructure to speed up some development tasks.

His example sets up a domain layer to interface user information for the system from a centralized repository. On top of that he builds his model extended from an abstract class called Zf_Domain_Entity. He also sets up a User collection, a User DAO and the user repository

Federico Cargnelutti has been posting a series of articles to his blog recently about domain-driven design, a method for organizing your code for maximum reuse between domains. He focuses on the "M" (model) in the MVC structure (model/view/controller) and how it can be separated out into a layer all its own - the domain layer. Here's the parts of his series so far:

• Domain-Driven Design and MVC Architectures - an introduction to the domain-driven concept and some definition of terms that he'll be using.
• Domain-Driven Design: Data Access Strategies - a look at some of the different data access methods (like Active Record, Data Transfer Objects and generic Data Access Objects)
• Domain-Driven Design: The Repository - illustrating how the user-created code would interface with a DAO instead of directly working with the database itself. It provides another abstraction layer that is more specific to your current application instance.