Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Ross Tuck:
Returning From Command Buses
Jan 22, 2018 @ 09:29:57

On his site Ross Tuck has a post that covers a common design pattern, the Command Bus, how it relates to CQRS and that they shouldn't return anything. In the post he takes some of the most common questions about using a command bus and tries to clarify with the correct answer.

The most common question I get about my command bus library is: “can commands really return nothing?” The second most common question is “Why do you let commands return something, don’t you know that’s Wrong(tm)?”

It’s easy to get hung up on form, not function. That’s a shame because command buses aren’t important. In the grand scheme of things, they’re completely, utterly, totally unimportant. It’s all about where the messages are going, not how they get there.

Still, let’s take a look at some myths about command buses.

The questions he tackles include topics like the relationship between CQRS and command buses, if you should be using them together (dependencies) and some discussion about return values and the "right" way to do things.

tagged: commandbus designpattern cqrs combination myth

Link: http://rosstuck.com/returning-from-command-buses

Asmir Mustafic:
Modular Application Architecture - Considerations
Jan 08, 2018 @ 12:54:36

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.

tagged: modular application architecture series part5 consideration designpattern plugin

Link: https://www.goetas.com/blog/modular-application-architecture-considerations/

Paul Jones:
Solving The “Widget Problem” In ADR
Jan 03, 2018 @ 12:54:43

Paul Jones has a post to his site covering a method he's worked up to solve the "widget" problem in ADR, the Action-Domain-Responder design pattern he worked on defining.

The “widget problem” is when you have several panels or content areas on an HTML page that have different data sources. You might have a main content area, then a calendar off to the side, with perhaps a list of recent news items or blog posts, a todo or reminder widget, and maybe other information panels. The problem is that they each have different data sources, and may not always be displayed in every circumstance — perhaps they are only shown to some users based on their preferences, or under certain conditions.

So how, in Action-Domain-Responder, do we get the “right” data for the set of widgets that are actually going to be displayed?

His answer is pretty simple, basically that the requests are handled the same as everything else but with more kinds of data contained in the "domain" of the response. He walks through a code example of a site that would pull out the set of widgets to show and inject them into the "payload" for passing back to the responder for output handling.

tagged: widget actiondomainresponder designpattern problem domain tutorial

Link: http://paul-m-jones.com/archives/6760

Loïc Faugeron:
PragmatiClean - Command Bus
Sep 20, 2017 @ 09:41:57

Continuing on from the first part of the series Loïc Faugeron has posted the next tutorial in the "PragmatiClean" series covering the use of the Command Bus pattern in your application.

The Command Bus pattern relies on 3 types of classes:

The first one is the Command [...] next is the Command Handler [and] finally there's a Command Bus interface allowing us to build Middlewares.

For each of these parts of the design pattern he covers what the part is and how it fits into the overall structure the pattern defines. He also looks at how it allows for easier adherence to the ideas of both "clean" and "pragmatic" code. The post ends with an example of implementing the Command Bus pattern in a Symfony-based application, building out each part and their integration.

tagged: pragmaticlean commandbus designpattern tutorial series part2

Link: https://gnugat.github.io/2017/09/20/pragmaticlean-command-bus.html

Paul Jones:
Slim and Action-Domain-Responder
Aug 23, 2017 @ 11:04:19

In a post to his site Paul Jones shows how an implementation of his proposed Action-Domain-Responder pattern might look when implemented with Slim, a popular PHP microframework.

I’ve had a warm place in my heart for Slim for a long time, and especially so since recognizing the Action-Domain-Responder pattern. In this post, I’ll show how to refactor the Slim tutorial application to ADR.

One nice thing about Slim (and most other HTTP user interface frameworks) is that they are already “action” oriented. That is, their routers do not presume a controller class with many action methods. Instead, they presume an action closure or a single-action invokable class. So the Action part of Action-Domain-Responder already exists for Slim. All that is needed is to pull extraneous bits out of the Actions, to more clearly separate their behaviors from Domain and the Responder behaviors.

He then works through each piece of the example application, first extracting out the Domain logic then building a Responder to handle the user interface functionality. He combines them to replace the current functionality, pointing out that the responder can now be tested separately from the user interface (templating system).

Now, for a simple case like this, using ADR (or even webbishy MVC) might seem like overkill. But simple cases become complex quickly, and this simple case shows how the ADR separation-of-concerns can be applied as a Slim-based application increases in complexity.
tagged: slim microframework actiondomainresponder designpattern adr tutorial refactor

Link: http://paul-m-jones.com/archives/6639

Paul Jones:
Domain Logic and Email Templates
Jul 18, 2017 @ 11:59:50

Paul Jones has a new post on his site sharing some of his thoughts about the placement of domain logic and email templates in an ADR (Action/Domain/Responder) structure. The post is an answer to a recent question he received asking how to organize emails being sent by service classes.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

He then provides what he sees as a good directory structure to help keep it all separated out. He also talks about the load sending emails can put on a system, when to move it to workers and how that impacts where the templating of the emails should be done.

tagged: domain logic email template adr actiondomainresponder designpattern structure

Link: http://paul-m-jones.com/archives/6619

Jeroen de Dauw:
Implementing the Clean Architecture
Feb 21, 2017 @ 10:41:45

In a recent post to his site Jeroen de Dauw looks at some of his own work and ideas around implementing clean architecture in PHP-based applications. The idea behind "clean architecture" is a focus on separation of concerns and dividing the systems into "layers" with contained logic in each.

Both Domain Driven Design and architectures such as the Clean Architecture and Hexagonal are often talked about. It’s hard to go to a conference on software development and not run into one of these topics. However it can be challenging to find good real-world examples. In this blog post I’ll introduce you to an application following the Clean Architecture and incorporating a lot of DDD patterns. The focus is on the key concepts of the Clean Architecture, and the most important lessons we learned implementing it.

In his post he looks at a real-world application (the Wikimedia Deutschland fundraising software) and how Domain Driven Design plays into the "clean" structure. He then walks through code examples, directory structures and lessons learned along the way (including bounded contexts and effective validation).

tagged: clean architecture tutorial guide domaindrivendesign designpattern

Link: https://www.entropywins.wtf/blog/2016/11/24/implementing-the-clean-architecture/

SitePoint PHP Blog:
Achieving Modular Architecture with Forwarding Decorators
Feb 17, 2017 @ 13:46:51

The SitePoint PHP blog has a tutorial posted from author Eugene Dementjev covering the use of "forwarding decorators" to create a more modular architecture for your application.

As your web application becomes larger, you certainly start to think more about designing a flexible, modular architecture which is meant to allow for a high amount of extensibility. There are lots of ways to implement such architecture, and all of them circle around the fundamental principles: separation of concerns, self-sufficiency, composability of the parts of an app.

There is one approach which is rarely seen in PHP software but can be effectively implemented — it involves using native inheritance to provide manageable patching of the software code; we call it the Forwarding Decorator.

The post starts out by defining the modular architecture and some of the basic concepts involved (including a flow graph or two). Then comes the examples - how as basic version of the system could be used, multiple modules modifying a single class and hooks/patching the code.

tagged: modular architecture forwarding decorators tutorial designpattern

Link: https://www.sitepoint.com/achieving-modular-architecture-with-forwarding-decorators/

QaFoo Blog:
Outside-In Testing and the Adapter and Facade Patterns
Jul 05, 2016 @ 10:47:03

The QaFoo blog has a post today about outside-in testing, two design patterns - Adapter and Facade - and how they relate.

As part of our workshops on Test-Driven Development we explain to our customers how testing from the outside-in can help find the right test-mix.

The technique puts a focus on test-driven-development, but instead of the traditional approach starts at the acceptance test level. The first test for a feature is an acceptance test and only then the feature is implemented from the outside classes first. [...] Outside-In testing leads to interfaces that are written from what is useful for the client object using them, in contrast to objects that are composed of collaborators that already exist. Because at some point we have to interact with objects that exist already, we will need three techniques to link those newly created interfaces/roles to existing code in our project

These three techniques are:

  • using the adapter pattern to interface with third party code
  • the facade pattern to "layer" your own code
  • continuous refactoring of interfaces/implementations

In this post they focus mostly on the adapter pattern. They show how to use it in interfacing with remote systems in a Symfony application (for example) based on a remote XML file. They also include the test to verify it's functioning correctly and the PHP code to make the mocks and interfaces you'll need for the test.

tagged: outsidein testing adapter facade designpattern refactor interface

Link: https://qafoo.com/blog/087_outside_in_testing_adapter_pattern.html

SitePoint PHP Blog:
Disco with Design Patterns: A Fresh Look at Dependency Injection
Jul 01, 2016 @ 11:26:44

On the SitePoint PHP blog there's a tutorial posted giving you a "fresh look at dependency injection" using the Disco library from bitExpert.

Dependency Injection is all about code reusability. It’s a design pattern aiming to make high-level code reusable, by separating the object creation / configuration from usage.

[...] Our very own Alejandro Gervasio has explained the DI concept fantastically, and Fabien Potencier also covered it in a series. There’s one drawback to this pattern, though: when the number of dependencies grows, many objects need to be created/configured before being passed into the dependent objects. [...] In this article, we’ll demonstrate the concept [of a dependency injection container] further with a newcomer in this field: Disco.

He starts with the installation of the library via Composer and starting up the built-in PHP web server for testing. With that up and running he shows you how to create an instance of the container and set up a sample service with the configuration in the docblock comments. The tutorial then talks about the service scopes, container parameters and shows it in action to create a simple controller handling frontend. There's a bit more about configuration, the container builder functionality and the creation of a response listener when routes are requested.

tagged: tutorial disco designpattern dependency injection di library

Link: https://www.sitepoint.com/disco-with-frameworks-and-design-patterns-a-fresh-look-at-dependency-injection/