Symfony Business Model and Symfony

If you are brave enough to get out of the confort zone and structure of applications over symfony and follow a more clean path you will may be facing some challenges on the road, like integration with ORMs (Doctrine).

In this particular post i will talk about about some strategies i have follow in the past and what i have learn from it.

Business Model and Doctrine Entities/Documents

The first strategy i follow was to keep the doctrine mapping under the bundle Entity or Document directory and inherit from business clases. Given that i want to leave the business package without any reference to database or framework i choose to use yaml or xml for the mapping language instead of annotations.

The first challenge with this strategy is that objects are created on the business model so when it gets to the entity/document manager it doctrine does not recognize it and throw and error. The way i found to handle this was to implement a fromBusinessEntity function on each entity/document class so before it get persisted or updated it go through this function and convert it self to an object under the doctrine scope.

This has a big downside, since you have to convert every object and those objects may have references, embedded documents or any other complex structure it will require a big logic to handle it, and with more code comes performance degradation.

The only good side of this approach is that developers that are use to use symfony as it is and do not have interacted with a model designed by package responsibilities may feel a bit confortable on where to find the entities/documents.

Business Model as Doctrine Entities/Documents

But i cant stop with that solution i feel it was not right so i decide to dig in to the doctrine mapping configuration. My findings were that we can actually tell doctrine were to seek for mapping references so we can do something like

# Doctrine Configuration
            server: "%mongodbServer%"
    default_database: "%mongodbDatabase%"
                    type: yml
                    dir: "%kernel.root_dir%/../../BusinessPackage"
                    prefix: BusinessPackage

This way your business classes can act as doctrine entities/documents reducing complexity on your framework business integration and dropping the performance degradation that may be introduced on previous approach.


Between previous approaches i personally choose the second one because i like to keep my code as clean as possible and business independently of frameworks.

It may be even a better way to this and im counting on it, so we can keep learning and improving.

Every time we decide to use a new approach on how to deal with frameworks, architecture patterns, code structure, etc; we put our self in front of a new challenge, we may have the experience from old projects we may try new approaches, the goal must be always learn from our mistakes and improve the next phase.


Fast development vs Agile development

In the past few years i have encounter the same issue in so many different companies and so many different projects, regarding the area or scope of the project, regarding if it was an stable and profitable software solution or an start-up, regarding the experience of the project manager; the battle between fast development and agile development its the biggest issue in today development teams.

Fast development

The concept of fast development is so false as its name, but let start asking why is this requirement even born.

The quick answer is a false attempt of apply Agile development. When you are required to deliver software solutions ASAP you are basically required to “fast-develop”, but its that right?

On projects on the category of start-ups, the budget its limited and in so many cases are really small, so the client always want to deliver more with less money and faster as light.

Most of the time in this “fast-develop” attempts, we, as developers; are force to code without testing, without design patterns, without research on the state of the art on what we are doing and even without common sense.

As professionals we should not accept this and deliver software solutions with great code quality, software solutions that can be easily extensible and flexible to changes.

On my personal experience, at so many cases i was put under this circumstances and force to deliver code with so low quality that 90% of the time requires refactoring and a lot of debugging. Shame on me.

That was not fast development at all, the main propose of the “fast-development” its try to deliver software solutions that works, and hopefully wont break. But how can you accomplish this with so poor design and cero good programming practices or principles applied?

The answer its clear, you can’t.

Agile Development

Agile does not mean fast, agile is about moving quickly and easily.

At software industry agile means to build the software solution step by step, delivering value at each step but taking all the measures to deliver it right.

That means, take the time to research, the time to design, the time to apply good programming practices and principles, the time to take choices with care, to think on value, to build good software solutions.

Its actually accountable that projects build upon Agile are in fact faster that those who use “fast-development”.

I took this little experiment on one project some time ago. I was team lead at the time and the team was using or at least trying to use SCRUM, so i begin to measure how fast the team was: based on if the team delivers or not on each sprint and how much fix of that value need to be re-introduce on the next sprint. The result was on a 40%-50% of that value, so in terms on how fast the team was the answer its cristal, only %50 fast.

So with that results over 4 whole sprints i propose a plan to actually be agile and deliver a good value for the same time as the first test, notice that the project was the same, an the team was the same, only the strategy changes. We now schedule time to discuss the solution, to research, to apply design patterns and to test the code. The measures where the same as the first scenario. The results where amazing, the team was 30%-40% faster at the first sprint, 40%-50% faster at the second sprint and 50%-60% faster at the two last sprints. Given that the team was force to think in another direction and we where working with a really bad legacy code, the results where amazing, the team was able to increase the speed at the end.

So what happens, the team keeps working on that bases and having a good retrospective at the end of the sprint, trying to look at sings that may lead to use the bad practices.

So as Robert C. Martin (Uncle Bob) advice on so many of his books and conferences:

By been agile, by applying design patterns and test your code; you will actually been faster by been slow

At the end even on those start-up projects with very limited budget use agile will provide a solution that ensure the quality that the client was expected from the start.


I know that much of this have its roots on professionalism and experience, but we should always look on better ways to do things, to build things. We need to encourage our self to battle and discuss the right ways, that is what make us professionals in the first place.

As a Software Engineer and as a Professional i toke a personal stance to explain, advice, educate and finally agree to code using Agile Development delivering software solutions at the greatest quality i can.

Symfony and Clean Architecture

I have been reading and viewing conferences, a lot; about architecture and SOLID principles, mostly from Robert (Uncle Bob) Martin and from other good sources like Mathias Verraes and Mathias Noback.


How many times do you find your self in front of a legacy project don’t even knowing a single piece of information about it.

So the first thing you see its the project directory structure, from it you can, maybe; identify the framework; but that doesn’t gave you any clue about the business rules.

One concept that caught my mind it’s the clean architecture.

As Uncle Bob says

Software architecture should be easily identified as architectural building blueprints

Lets take for example this Architectural Building Blueprints

Church Plan 152 Floor Plan

Its easy to identify a church in that, we can be confuse for a second with a theater but the little cabins surrounding the inner room gave it away that are confessionals and only church have those.


In this case this its a real theater. We can see the balconies, the great space for the scenario.

So the details on the blueprints gave us an idea of the intention, the purpose; of that building.

So the questions is: How the blueprints for a software architecture looks alike?

Lets take an example of a Symfony2 application


If we where to identify the purpose of this software we will only be able to identify only one detail, that its build to be a web delivered app and that maybe Symfony2 its the based framework. No single detail about what its the real intention of this software. This its because almost all the frameworks we use force us to follow its blueprint and we forgot that our main architecture, our business rules, our product intention; should not be case about how its delivered to the final user, we where force to hide our architecture inside the delivering mechanism. As Uncle Bob says:

The web is an I/O mechanism

So how to

This post its about a little example of how can you accomplish this with Symfony. Recently i force my self to follow this rules and good practices, keep my architecture as clean and SOLID as possible and i made it with my web framework of preference Symfony.

So lets try to identify this product through my new blueprint

Screenshot from 2015-08-26 11:15:24

We have Costumer, Post, Purchase, Shipment; from that we can identify an e-commerce solution. We can also see Comment, Message and Notification; that gave us the idea that a social and real time integration in that e-commerce. Lastly we can see development tools and framework in there; sure we need those two to make the whole solution works but those are not the main reason to exist. We can even move those two to another repository, we can even have a dedicated repository for each one of the main details of our architecture, that its up to you; but sure we can easily identify our software identity, our product reason to exists.

Now our blueprint explicitly expose the intention of this software. We manage to leave as a single detail the delivering mechanism, we don’t even know from this blueprint if its the web, it can even be console delivered; sure we can open the framework detail and that will lead us to that knowledge that its web delivered but up front we can not be sure about it.

What do we need to do so Symfony can understand our architecture, easy lets import it on the aoutoload.php file like this:

$loader->addPsr4("Costumer\\", __DIR__.'/../../Costumer', true);
$loader->addPsr4("Post\\", __DIR__.'/../../Post', true);
$loader->addPsr4("Purchase\\", __DIR__.'/../../Purchase', true);
$loader->addPsr4("Shipment\\", __DIR__.'/../../Shipment', true);
$loader->addPsr4("Comment\\", __DIR__.'/../../Comment', true);
$loader->addPsr4("Notification\\", __DIR__.'/../../Notification', true);
$loader->addPsr4("Message\\", __DIR__.'/../../Message', true);

Our architecture its much cleaner now. We need to keep following the SOLID principles and the good design patterns, but its a good start.


Besides any good practice proposed by frameworks, no matter how fast you wanna go; dedicate time to design a clean architecture will pay off at the end and you will be going even more fast that you thought.


I want to gave all the credits for this post to Robert C Martin since the reason of this post its only to extend this great knowledge.