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.

On the Laravel News site there's a new post sharing some of the changes to the "resources" directory that are coming in Laravel v5.7.

Taylor Otwell announced that in Laravel 5.7 the resources directory will be flattened instead of having an assets folder.

The post includes "before" and "after" examples of the directory structure change and shares some Laravel Mix configuration changes that can be used to move the assets pre-release of v5.7.

Sergey Zhuk has posted another ReactPHP tutorial to his site, this time focusing on working with the filesystem from a ReactPHP application.

I/O operations in the filesystem are often very slow, compared with CPU calculations. In an asynchronous PHP application this means that every time we access the filesystem even with a simple fopen() call, the event loop is being blocked. All other operations cannot be executed while we are reading or writing on the disk.

[...] So, what is the solution? ReactPHP ecosystem already has a component that allows you to work asynchronously with a filesystem: reactphp/filesystem. This component provides a promise-based interface for the most commonly used operations within a filesystem.

He starts the code with a bit of setup, creating the initial event loop, the related Filesystem instance and a pointer to a "test.txt" file. He then walks through the basic filesystem operations and the code required: reading in the file contents, creating a new file and writing content back out to a file. The next section goes through the same functionality for directories. He ends the post with a look at symbolic link creation, read and delete operations.

In a post to his site Matthieu Napoli shares some recommendations about how to organize the code in your application using a "domain modules" approach. This is an organization method that relates the code based on functionality it relates to rather than the type of object it is.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code [and] how to organize teams.

Regarding “how to organize teams”, we were discussing Spotify’s Feature teams. In a “classic” organization, teams are usually formed by grouping people based on their job title. [...] But in a “feature team” organization, teams are organized… by features. [...] The pros of this kind of organization are numerous and I do not intend to go over them here. But what does this have to do with code organization?

He starts with the "classic" code structure - organized by each item's type (ex: Entity, Service, etc). He then suggests reorganizing it move by what it does in the application, namely which module it belongs in best. He briefly touches on dependencies, "agile design" and the differences between a normal "product" and a "product" in e-commerce. He then applies these ideas and shares a domain organized directory structure, trying to reduce the overall complexity of the structure and the overall cohesion of the codebase.

Fabien Potencier has a quick post to his site that may be of interests to the Symfony developers out there related to directory updates coming in Symfony 4:

After a long discussion in the community, the directory structure has been slightly changed.

etc/ was renamed to config/, and web/ to public/. My blog posts about Symfony 4 have just been updated to reflect these changes.

He also includes instructions about how, if you're already running a Symfony Flex application, you can make these changes manually including updating the Flex version.

Fabien Potencier continues his look at what's coming in the next major release of the Symfony framework (v4) in this new post to his site. In it he talks about changes to the default directory structure that Symfony 4-based applications will use.

Symfony 3 came with a slightly different directory structure than Symfony 2. Symfony 4 will also come with a reworked directory structure. Mostly incremental adjustments to support new features and best practices.

The Symfony 3 directory structure introduced a more standard Unix-like directory structure, with less sub-directories. Symfony 4 keeps going in that direction.

There's six changes he mentions specifically, each with a brief summary of what they'll contain:

• Tests under tests/
• Templates under templates/
• Configuration under etc/
• Source Code under src/
• Temporary files under var/
• Web files under web/

He ends the post with a quick note that, while these will be defaults, all of it is optional and these directories will be created automatically if they don't exist.

The Zend Developer Zone has a new post with information about some updates from the WordPress project about what plugin authors must do to be compliant with the rules of the WordPress Plugin Directory.

After five years, the WordPress plugin team has updated the Plugin Guidelines. These are the guidelines that WordPress plugin authors must comply with to be included in the WordPress Plugin Directory.

The guidelines were soft-launched last month so that they could be vetted by the larger plugin developer community community. On November 1st, 2017, they were officially announced “Revised Guidelines Are Live” by Mika Epstein.

Overall, these guidelines are good. They are solid, well communicated and clear to anyone who reads them.

The ZDZ post focuses in on just two of the guidelines that were updated with a few brief thoughts in each:

• #4. Keep your code (mostly) human readable
• #9, The plugin and its developers must not do anything illegal, dishonest, or morally offensive

They point out that, while the intent is good for #9, the term "morally offensive" is very broad and could be interpreted in many ways by many different groups.

In another of his series of posts about the upcoming version of the Laravel framework (v5.3) Matt Stauffer focuses in on some of the changes in routing that are coming down the line.

The last few versions of Laravel have showed the way routing works shifting around a bit. This is usually a sign that we're feeling some sort of pain—something feels off—but haven't found the perfect solution yet. In 5.3, we may have found it.

He starts by looking at some of the routing changes that happened when v5.2 was released including the change away from two groups ("web" and "api"). In v5.3 the major change is the location of the routes definitions containing all of the routes in your application. In the update, this relocation (into a directory) allows you to define multiple route configurations that can be individually changed based on features rather than one global place. He also includes an example of how you can set up your RouteServiceProvider to load in custom configurations as well.

The SitePoint PHP blog continues their series looking at the features of the appserver.io project in this second post covering its server configuration, directory structure and how it handles threads during processing.

In the first part of our Appserver series, we discussed the very high level differences of Appserver’s architecture to standard web server stacks and got you up and running with an Appserver instance.

[...] In this part, we will be exploring the Appserver architecture a bit more in depth. We will go through the concepts of the different contexts and the parts of Appserver you get out of the box, which cover some of the ground most of the popular PHP frameworks offer. We will also configure the web server and look into an application’s structure. Once we are finished, you should have a fair understanding about Appserver’s contexts in relation to threading, the web server, and its setup.

They start with the threading functionality, showing how "contexts" come in to play and how the code executes as long as this context is alive. The post then gets into some of the code-related differences with using appserver such as extra annotation handling and AOP (aspect oriented programming) practices. From there they get into the tech behind the scenes: configuring the web server, setting up a virtual host and pointing it at the sample application. Finally they talk about the servlet engine and the server's directory structure underneath.

On the NetTuts.com site today they have a new tutorial (screencast) posted showing what the changes are in the directory structure of Laravel 5.

The newest version of Laravel was released in February, and the most noticeable change in version 5 is the new directory structure. In this short video tutorial, I'll explain exactly what's changed and why.

The video is a part of a larger series and is one of two free videos for it. The remainder of the series covers things like middleware, contracts, events, forms and validation as well as the command bus and its use.