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.

The PHP.net website has a note posted about the restructuring of the manual

A few weeks ago the manual was restructured to improve navigation and make room for per-extension chapters and usage examples along with improved documentation for object oriented extensions.

Changes were made in the function reference and in the predefined variables and context options/parameters sections as well as information on upcoming features like namespaces, late static bindings and Phar (to be included in PHP 5.3). The manual is now covered by the CreativeCommons Attribution license.