In this article, we're going to have a closer look at how to organise our applications directory tree.

He shows how to create a new project with the "empty edition", a skeleton for creating a basic Symfony framework with some of the basic boilerplate already in place. He shows the resulting directory tree and creates a new AppBundle for his new development. Initially he put the bundle under the main directory so he then shows how to decouple this and move bundles and libraries out into a src/ directory outside of the main application directory in the skeleton.

The SitePoint PHP blog has an article posted by Vitalij Mik showing you how to merge the concepts of "clean code architecture" and test-driven development to make solid, maintainable code. The ideals of the "clean code architecture" were first proposed by Robert C. Martin in this post on the 8thlight blog.

The idea was to create an architecture which is independent of any external agency. Your business logic should not be coupled to a framework, a database, or to the web itself. [...] Frameworks will continue to change and evolve. With composer, it is easy to install and replace packages, but it is also easy to abandon a package (composer even has the option to mark a package as abandoned), so it is easy to make “the wrong choice”.

In this tutorial, I will show you how we can implement the Clean Code Architecture in PHP, in order to be in control of our own logic, without being dependent on external providers, but while still using them. We will create a simple guestbook application.

He starts with a first test, evaluating that a list of entries for the guestbook is empty. The code shows the "fakes" for the different object types Uncle Bob recommended in his article and how it fails because none of them exist yet. He extends this with a "can see entries" test and then starts in on the "use case" class to start making the test pass. He updates the case to pull in entries from the repository, another external dependency created later in the tutorial. He then goes through creating the classes for the "fakes" in the test and refactoring the test based on some of his changes during their development. In the remainder of the post he talks about the independence of the current setup and how to add in pagination functionality on the entries objects.

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.

Let’s talk about Event Listeners. Do you know what an Event Listener is? Well, if you are used to working with Symfony, then you should know what is intended for. If you don’t, don’t hesitate to take a look at the Symfony documentation. This post aims to start a small discussion about how an Event Listener should look like if we really want to keep things decoupled.

The starts with a brief summary of the post (tl;dr) for those in a hurry but goes on to explain things in a bit more detail too. He starts by laying a foundation, introducing what event listeners are. He also shows how they're commonly implemented and used (in Symfony2 specifically but it applies more generally too) to trigger actions in applications. He suggests decoupling things a bit more from the flow of the action and allowing, in this case, access to both the order and the customer (on a "order created" action). He takes it one step further and decouples the sending of an email into a service and then creates an instance of this when needed in the event and not before.

On the Digital Ocean blog there's a new post with a "practical overview" of how to effectively scale PHP applications, specifically as it relates to horizontal scaling not vertical.

Shipping a website or application to production has its own challenges, but when it gets the right traction, it’s a great accomplishment. It always feels good to see the visitor numbers going up, doesn’t it? Except, of course, when your traffic increases so much that it crashes your little LAMP stack. [...] But fear not! There are ways to make your PHP application much more reliable and consistent. If the term scalability crossed your mind, you've got the right idea.

The article starts with a brief overview of what scalability is and the main difference between horizontal and vertical scaling (scaling out vs scaling up). They then get into a bit more detail about what horizontal scaling is and how it commonly works in relation to the average PHP application (complete with diagrams). They also talk about some things you can do inside your code to help make things flow a bit more smoothly including decoupling between services and user session/file consistency measures. There's also a bit at the end about load balancing but as that depends a good bit on what technology you're using and the actual load, they just provide an overview and some links to other articles and tutorials with more information.

In his latest post Matthias Noback shares a few hints on how yuo can decouple from using a service locator in your application. A service locator (much like a dependency injection container) is a centralized place for storing and creating instances of objects in your apps with a bit more structure than just random "new" calls.

"Decoupling from a service locator - shouldn't that be: don't use a service locator?" Well, not really, since there are lots of valid use cases for using a service locator. The main use case is for making things lazy-loading (yes, you can also use some kind of proxy mechanism for that, but let's assume you need something simpler).

He starts with an example dispatcher class and shows how to modify the flow so that "expensive" listeners are only created in the correct context. He also suggests a few other methods for handling the idea of dependency inversion a service locator provides: using closures/callables instead of classes and using something called a "synthetic service", one set up at runtime as synthetic and used as needed on a manual basis (like in his bundle example).

In his latest post Paul Jones recounts a Twitter-based discussion that happened between Taylor Otwell (@taylorotwell) and others on Twitter about the different types of coupling in libraries or applications. The discussion focused around three different types and their definitions: loosely-coupled, tightly-coupled and de-coupled.

The quotes from the conversation come from Taylor, but Paul includes some of his own thoughts in response (things better expressed in more than 140 characters. He talks about some of the assumptions that were made during the discussion, the general knowledge level of "basic programming terminology" and how Paul views the definition of "decoupled".

If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. [...] The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

He talks about how one of the main goals of the packages that make up the Aura project is to be decoupled from the start and how that can help with changing requirements/dependencies down the road. He also defines what he sees as "loose" and "tight" coupling, largely defined by the packages required in the "composer.json".

In a recent post to his site Matthieu Napoli looks at some first steps you can take to help decouple packages in your application. He describes a few considerations and methods to think about as you try to break those chains.

Decoupling packages is a hard thing. There are not a lot of options, and this blog post is about how some options are better than others.

Let’s say for example that you are writing a “package”, or library, to respond to HTTP requests (that kind of package could be considered the basis for a web framework). How do you handle routing? If you write your Router package as an independent package (which is good: small and specialized packages are more reusable and maintainable), you might not want to couple the HTTP package to the Router package: you want to leave users free to choose the router of their choice. So, what are your options to make the HTTP package and the Router package decoupled from each other?

He looks at a few different approaches including focusing on event-driven programming or splitting things along "edges" and making interfaces/adapters to hook them together. He also puts an emphasis on standardizing interfaces, even those outside of your own internal to the application (think the set of PHP PSRs).

Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.

The general belief is that controllers are the most tightly coupled classes in every application. Most of the time based on the request data, they fetch and/or store persistent data from/in some place, then turn the data into HTML, which serves as the response to the client who initially made the request. [...] In this post I demonstrate that this high level of coupling is definitely not necessary. I will show you how you can decrease coupling a lot by taking some simple steps. We will end with a controller that is reusable in different types of applications, e.g. a Silex application, or even a Drupal application.

In this first part he focuses on a few places where the common practices lead to some unnecessary coupling between the controller and framework:

Using the framework helper methods

Using dependency injection (manually injecting instead)

Making the controller a service instead

The next post in the series will look at the use of annotations and how to refactor them out of the controller to remove yet another coupling point.