Commands, events, queries - three types of messages that travel through your application. Some originate from the web, some from the command-line. Your application sends some of them to a database, or a message queue. What is the ideal infrastructure for an application to support this on-going stream of messages? What kind of architectural design fits best?

This talk provides answers to these questions: we take the hexagonal approach to software architecture. We look at messages, how they cross boundaries and how you can make steady communication lines between your application and other systems, like web browsers, terminals, databases and message queues. You will learn how to separate the technical aspects of these connections from the core behavior of your application by implementing design patterns like the command bus, and design principles like dependency inversion.

If you’re a programmer you make design decisions every second. Statements, functions, classes, packages, applications, even entire systems: you need to think, and often think hard, about everything. Luckily there are many useful design principles, patterns and best practices that you can apply. But some of them merely expose code smells. Others only help you design your classes. And some are applicable to packages only. Wouldn’t it be nice to have some more general, always useful, invariably applicable, foundational design principles?

Before Symfony was spelled with a capital “S” there was another symfony, the first version of the framework. It already meant a lot to me at the time. But with the arrival of Symfony 2 it became clear that something very important was happening in the world of PHP programming. It appears that this framework is able to turn amateur website makers (like I used to be) into actual software developers. What is the secret? What makes Symfony so special? And why am I still hooked?

With many great tools available for sharing packages of PHP code, it is now up to you as a developer to design these packages well. You have to decide what to put in a package, when to split a package and on what other packages you can safely depend.

You will learn how to make good decisions about your package design and release reliable, highly usable and therefore highly esteemed packages of PHP code.

You have created one or more Symfony applications. You found out how to leverage the framework to rapidly develop some features. As the application (and your team) got bigger, you started looking for a way to prepare your application for a long and prosperous life. After reading about DDD, BDD, events, command buses, layered and hexagonal architecture, you are left wondering: how can I apply these cool ideas to my everyday Symfony projects?

Class dependencies are things that your classes need. You may be used to fetching them yourself, but what if someone else could bring them to you? This is what the Symfony DependencyInjection Component can do for you. It converts service definitions to executable PHP code. The result is that all the dependencies of your classes will be injected as constructor arguments automatically.

Since Drupal 8 heavily uses dependency injection, you need to learn as much as you can about this interesting subject. In the workshop “A healthy dose of dependency injection” Matthias tells you all about the design principles behind dependency injection (like Inversion of control and Dependency inversion). And of course, you will learn all the little details of working with service definitions.

A Series of Fortunate Events

What is an event really? How can you best describe an event in your code? What types of events are there, and how do you decide whether or not to implement something as an event?

In this talk we start with a straightforward command-only piece of code. We extract events from it and start moving the event handling code out, trying different design patterns on the way. First we try Observer. Then we introduce event data, event handlers and a Mediator between our code and the event handlers. Finally we pick a well-known event dispatcher implementation (the Symfony EventDispatcher) and see how it uses the Chain of Responsibility design pattern to control the entire flow of a web application request.

You have created one or more Symfony applications. You’ve learned how to use the framework to rapidly develop some features: you wrote some controllers, entities and templates. But as the application (and your team) got bigger, you started looking for a way to prepare your application for a long and prosper life. Still, after reading about DDD, BDD, events, command buses, layered and hexagonal architecture, you are still wondering:

How can I apply these cool ideas to my Symfony applications?

The Bundle system is “one of the greatest and most powerful features of Symfony2”. Bundles contain all the files related to a single feature of your application: controllers, entities, event listeners, form types, Twig templates, etc. But how much of that actually needs to be inside a bundle?

In this talk I take a bundle, containing all those different types of classes, configuration files and templates, and strip it down to the bare necessities. And I promise that after moving many files out of the bundle, at the end everything still works.