On the Sticher.io site there's a new tutorial posted where Brendt shares some thoughts about domain driven design and splitting codebases to make them more maintainable and logically separated.

In this post we'll look at a different approach of structuring large code bases into separate domains. The name "domain" is derived from the popular paradigm DDD, or also: domain driven design.

While many concepts in this post are inspired by DDD principles, they will not follow every rule set by the paradigm. In our context, "domain" can also be named "module". A "domain" simply refers to a category of related stuff, that's it.

The post then starts with a definition of what a "domain" is and how it relates to functionality in an application (a Laravel app in this case). He gives an example of restructuring the code into "domains" of functionality rather than thinking about their types (enums, rules, etc). He provides a new proposed directory structure for these domains including folders for Actions, Exceptions, Rules, Status and ValueObjects. He then walks through several of these categories and gives a bit more detail about what's inside and some of the functionality those files might contain.

Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

In his latest post Wojciech Sznapka wonders if Symfony2 is actually MVC or if it's just the "C" and "V" in the equation with the "M" (Model) layer being left wide open.

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.

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.