In a post to his site Matthias Noback looks at an interesting idea when it comes to the structure of your code: the idea of negative architecture and making assumptions.

In "Negative Architecture", Michael Feathers speaks about certain aspects of software architecture leading to some kind of negative architecture. Feathers mentions the IO Monad from Haskell (functional programming) as an example, but there are parallel examples in object-oriented programming. For example, by using layers and the dependency inversion principle you can "guarantee" that a certain class, in a certain layer (e.g. domain, application) won't do any IO - no talking to a database, no HTTP requests to some remote service, etc.

[...] A negative architecture is what's "between the lines". You can look at all the code and describe a positive architecture for it, but given certain architecture or design rules, there's also the background; things we can be sure will never happen.

He goes on to give a few examples of "negative architecture":

• "An object does nothing meaningful in its constructor"
• "An object doesn't also fetch dependencies statically if it also gets any number of dependencies injected"
• "If a class is not marked final, it has at least one subclass"
• "If a property is not marked "private", it's used by at least one subclass"
• "An abstract class won't use methods that aren't part of its published interface"
• "If an object has one public method, it won't have any public static methods"

For each item in the list there's a summary (and sometimes code) included to help clarify the point.

Matthias Noback has continued his series of posts covering mocking and testing at the "architectural boundaries" of your application. In this second post he offers two more suggestions of these "edges" where mocking could be useful: filesystem interfaces and randomness.

In a previous article, we discussed "persistence" and "time" as boundary concepts that need mocking by means of dependency inversion: define your own interface, then provide an implementation for it. There were three other topics left to cover: the filesystem, the network and randomness.

He starts with the mocking of the filesystem handling and makes the recommendation of using either vfsStreamor Flysystem to provide an interface that's more easily testable. These libraries abstract away the filesystem and make it easier to mock out the functionality rather than going directly to PHP's filesystem functions. His second example, randomness, is a bit tougher as the output isn't predictable. He still recommends abstracting it out, however, and offers suggestions as to what might be possible to test.

Asmir Mustafic has continued his series looking at building modular applications with part five looking specifically at some of the considerations and ideas to keep in mind when developing your modular applications.

This is the fifth post from a series of posts that will describe strategies to build modular and extensible applications. In this post we will take a general overview on how some popular design patterns and things to keep in mind when creating plugin based applications.

[...] Anthony Ferrara (alias ircmaxell), in this post blogged about the use of software patterns to implement plugin-based architectures. It is a great article and I suggest everybody to read it. As it is clear from the article, each of this software patterns has a specific use case and the choice of which one to use depends on which the of integration we want allow for the future plugins.

The article starts with a brief recap of some of the more common design patterns including the Observer, Strategy, Decorator and Chain of Responsibility. It then covers some quick uses of these patterns and shares two tips when developing a plugin system for the application and links to good examples for reference.

Rob Allen has a post to his site for the OpenWhisk (a serverless cloud platform) users out there that want to use Composer to install dependencies required by your application.

When creating new OpenWhisk actions in PHP, It's likely that you'll want to take advantage of the rich ecosystem of Composer packages on Packagist.org.

The OpenWhisk PHP runtime has you covered with some pre-installed Composer packages and also the ability to upload your own using a zip file.

He starts by mentioning the two packages that come installed by default: Guzzle and the ramsey/uuid library. He then gets into the upload of your own project files as a ZIP file and how to install the package locally, bundle it up into this archive and push it using the wsk command line tool.

For those dealing with APIs on a daily basis (or even the casual API-er) you'll find this post from Phil Sturgeon interesting. In it he takes on the opinion that's shared in this article from Pakal De Bonchamp that "REST is the new SOAP".

Enough people have asked me about the article REST is the new SOAP that I felt it justifies a write up. [...] The entire article is full of common misunderstandings about REST and HTTP. Despite dedicating my career to trying to educate people through these confusions, they continue to be rife. Clearly I am not being loud enough, writing effectively enough, or doing a good enough job. That is the frustration you might hear in my writing, but nothing is aimed at the author.

In his post Phil goes through the original article, pulling out quotes and responding to them one at a time. He shares opinions on HTTP verb operations, REST architecture, HTTP response code usage and the use of caching and statelessness in the API functionality.

Asmir Mustafic has kicked off a new series on his site with an introduction to modular application architectures. In the series he will work through the creation and management of modular applications as inspired by a session he attended in 2011.

When developing a software, one of the most common steps is taking care that the resulting application is extensible and modular.

Let's suppose we have our application or library. If we see it from outside, often it looks as a single thing. [...] As the application grows we can continue adding components... but this comes with a price. Components often knows too much of our application and there is a delicate equilibrium of dependencies between them and our application. When not handled carefully, a small change in one component might require changes in many other.

As a rule of thumb, I personally try to follow as much as possible the Acyclic dependencies principle Another way to allow extensibility but keeping the application "clean" is to introduce modules.

He starts by talking about modules and the major part they'll play in the overall architecture. He explains why modules are so key to the overall structure and what kind of advantages they bring along with their use. He spends the remainder of the post looking at some of the main challenges they'll face including the file/directory structure definitions, module registration methods and the configuration of each of the modules.

On the Trivago Tech blog they've shared some of their experience in continuous performance improvements in PHP applications and how the Blackfire.io service helped them get their best performance.

Our mission is to provide the user with the ideal hotel at the lowest rate. Our backend consists of several services written in different languages. To succeed at this goal we do complex tasks in our main application developed in PHP. While doing this we need to keep the website as fast as possible.

We started to look for some tool that could help us identify performance issues in our code base. We evaluated Blackfire and decided that it was a good fit for our use case.

The article starts by answering the question of "why Blackfire?" and continues on, showing how they integrated it with their workflow. They use the SaltStack tooling to set up servers and configure them so it was just a matter of integrating the Blackfire agent and probe extension via that. They include an overall diagram of how it fits into the architecture and how they worked around the lack of Bitbucket server support. The post finishes with some examples of performance metrics from before and after the optimizations from their results stored in InfluxDB.

In this new post to his site Herberto Graca has posted the latest part of his "The Software Architecture Chronicles* series, focusing this time on event-driven architectures.

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Using events to design applications is a practice that seems to be around since the late 1980s. We can use events anywhere in the frontend or backend. When a button is pressed, when some data changes or some backend action is performed.

But what is it exactly? When should we use it and how? What are the downsides?

He starts by talking about the "what", "when" and "why" of using events to drive the architecture of the system, going into each of the topics in a bit more depth:

• To decouple components
• To perform async tasks
• To keep track of state changes (audit log)

He then goes on to talk about common patterns for event-driven applications including event notification, event-carried state transfer and event sourcing.

In a recent post to his site Herberto Graca shares some of his thoughts around packaging and namespacing and how it relates to the overall architecture of your application.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems: components, relationships between components [and] principles guiding the design and evolution of components and relationships.

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

The post then goes on to talk about "spaghetti" architecture, what makes for a more maintainable codebase and how this impacts the overall structure. He shares a few of the "packaging principles" previously defined by Robert C. Martin and the concept of "screaming architecture" (it should be very clear about how it's structured).

In this post to his Medium blog Pawel Mikolajczuk shares some helpful tips for getting the most performance out of your Twig output with some custom caching techniques.

In Superdesk Publisher we have implemented Mutlitenancy with possibility to have multiple themes (but one activated). To make process of switching, uploading and updating themes for tenant we had to came up with solution to clear cache only for one particular theme not the whole instance (with many organisations and tenants).

To achieve that we created custom Twig Cache class.

He then shares the code for the class, extending the base Twig filesystem caching, to work with the multi-tenant architecture. It ensures that the output from one account is completely separate from another, preventing concerns of the wrong data being shown to the wrong user. He also shows how to enable it in the application configuration (Symfony) and a custom "compiler pass" class to finish the integration.