The question is: where is Model layer in Symfony2? My answer is: there's ain't one and it's good.. Symfony2 isn't hardly bounded with Model layer, as it could have been seen in first version. We can see many Active Record model implementations in modern web frameworks such as Ruby on Rails, Django and symfony 1. I'm not saying those solutions are bad. The main problem was, that big systems maintained by plenty of developers changing over time tends to have a messy codebase. The common place to locate business logic were Model layer. The result of that approach were huge model classes, randomly structured Table/Peer classes full of static method and general feeling that system is hardly impossible to maintain anymore.

He talks about the main problem that comes from this style of coding - overly complex systems - and one possible way to help mitigate them using domain-driven design practices. He lists a few of the things that Symfony2 comes with that could be helpful for this method including the dependency injection container, the use of entities, repositories and value objects.

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.

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.

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

• 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.