Looking back at my old blog posts, I think it’s good to write down a more balanced view on application architecture than the one that speaks from some of the older posts from 2013 and 2014. Before I do, I allow myself a quick self-centered trip down memory lane.
Why Symfony? Seven facts
The archive tells an interesting story about how my thoughts about software development changed over time. It all started with my first post in October 2011, How to make your service use tags. Back in those days, version 2 of the Symfony framework was still quite young. I had been working with symfony (version 1, small caps) for a couple of years and all of a sudden I was using Symfony2, and I absolutely loved this new shiny framework. I learned as much as I could about it (just as I had done with version 1), and eventually I became a Certified Symfony Developer, at the first round of exams held in Paris, during a Symfony Live conference. During those years I blogged and spoke a lot about Symfony, contributed to the documentation, and produced several open source bundles. I also wrote a book about it: A Year With Symfony.
The Naked Bundle
But then some cracks began to appear in the relationship between me and Symfony. Posts like Some things I don’t like about Bundles and Unnecessary contrapositions in the new “Symfony Best Practices” are telling about this period. I struggled with the thing that I had started to love so dearly. Trying to earn back my freedom, I started frantically cutting away the framework’s tentacles. This resulted in several posts, in which “framework independence” was a central concept. Amongst other things, I created a series about framework-independent controllers and talk called The Naked Bundle, which is about my quest to remove as many things as possible from the bundle, making it an almost optional concept in a Symfony application.
Now that the framework was no longer my safe haven, there was a period in which I worked on more basic programming topics, like SOLID and Package Design. In parallel to working on leaving behind Symfony as the base for everything I did, I started working on a book, Principles of PHP Package Design. Eventually, I made “PHP” an implementation detail for this book, and it was released as Principles of Package Design.
I don’t know how it happened, but all of a sudden I was fascinated by hexagonal architecture and command buses – two things that don’t necessarily belong together as I know now, but which nevertheless formed a great source of inspiration. I even started a training tour through Europe about the topic. The command bus obsession resulted in a series of blog posts as well as an open source library called SimpleBus. This library was developed at the same time as Tactician was. This library is the go-to SimpleBus alternative created by Ross Tuck, with whom I shared the obsession. We teamed up and around that time started touring together with the PHP Architecture Tour. On day 1 of the workshop I did my hexagonal training, on day 2 he did his DDD training, from which I learned quite a lot.
“Advanced Application Architecture”
Combining views, knowledge and experience, finally resulted in something that I call in my trainings an “Advanced Application Architecture”. It should actually be called “Simple Application Architecture”. If you’re used to developing “Symfony applications”, or “Laravel applications” it may look like a bunch of verbose stuff, but I’ve come to like it a lot.
Coming at peace with “the framework” has been quite an important event for me. I’ve come to realize that there’s a time and a place for everything, even for the framework. That place is the Infrastructure layer and you can fully embrace any kind of RAD-stupid thing your framework offers, as long as it stays inside that layer, and nothing of it trickles down into either the Application or gd forbid the *Domain layer.
In another post I will lay out to you the basics of what today I think is a good application architecture (I’m sure it won’t stop at this, but at least I wanted to document my current views somewhere…).