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.