 Okay. Frameworks are very helpful to solve common problems and helping us to do it. But what happens if we have to change the framework of... Or there is a new version and we have to update. So in this talk I will try to explain how our experience in the company I work, we try to go over that. My name is Miguel Gallardo. I'm from Argentina. Yes, far, far away. I'm far, far away from home. I was just trying around Asia and get here. I have more than 15 years working with PHP and calling currently for a U.S. company called Propoint. So everything started because we get the mission to add a new feature to our current product. The main product of our company is a point of sale software. The code for it is like 10 years old. A lot of developers working on it along the time. When we started checking on the code to add the new feature, we found that the code was too ugly, so ugly to keep working on it. We start figuring out that we need to change that. So we found that all the business logic were all mixed with all the other spaghetti code. This was started 10 years ago, so no frameworks, no best practice, not everything. Test? No, not at all. No one. So we start thinking about this and how we can add the new feature. We are working on... So we're starting on making a new one, but the product is so big, so we cannot do everything. So we start thinking, oh, okay, let's do the new feature in a new code base with all the technology that is now frameworks, new PHP versions, unit testing. But we have to keep the old code running. So we start working on it. Mostly that we can... We was able to do that using the Strangler design pattern. But with this design pattern, we achieved two independent code from the old product. But then we started... Oh, but we are still depending on the frameworks. So what's next? We're starting with that. Then we go... We get into a concept that is decoupling. So what is decoupling? That is the question that we first do. The decoupling is a negative word, so the concept is copling. Basic copling is how much is... Are related every part of the code, each one. And in this case, how much we are involved with the framework, how much we are depending on the framework. What can we do to avoid that? So one of the benefits of decoupling is easy to see here, but in the code when you have a lot of mixed code and spaghetti code, it's not easy to see these benefits. Basically we made the code only work in every environment, every framework. So our code was using symphony. So I will focus more on symphony, but it's for every framework, every library. So one concept that we have in mind during all these stages is the frameworks are kinetic and solve problems that we all have in the building of application outside and that we don't want to invent the wheel, but it's not part of the project, it's not part of the core of the business. So we have that in mind. The framework is not part of the application. And then this is how it's mostly an application inside a framework, using a framework. So we can isolate these three parts or two parts mostly. The one that is fully depending on the framework for the basic of the applications, meaning that access or all the input output and that. The other part is the code that is not related to anything from the framework or the environment, but just the business logic and the core of the business. So we start splitting that in three main concepts, services, repositories and entities. We start working on that kind of paradigm. But before starting showing the code and what means each of these concepts, we set some rules that we try to follow. These rules are mostly like a cost style also and some rules for developers. So there are rules that can be broke because some are very hard to follow, but we try. One of these is the level of the meter. That basically is that each piece of code should be no less than, should we have only a limit knowledge of the other parts of the application or the piece of code to be only one small piece and isolate for every other piece. This small process is like an easy way to see. Only talk with friends and not with strangers. So it's an easy way to remember. The other one is the single responsibility principle. This is to avoid to have a huge class or a huge piece of code doing a lot of things. So if the piece of code is only for a customer, only holds the customer data, but nothing else, including the entity, for example, that we'll see on the next slide. Only holds the data, but doesn't take care of the, of saving the data or getting, just is a container of the data. This is also another concept that we have, that is we need to add some functionality to our entity. We should try to extend and not modify the previous entity. This is also to avoid to start adding functionality to a piece of code or something like that. So starting with the parts of the stack, the first one is the entity. Only is representing a single record of data. Not even a, it's not a title or a database registration only holds the information and the description of the data that we are using. This part is only, it doesn't include anything from the framework. It's just a simple PSP class. For example, this one for customer, only if we can see here that it's only keeping the data in runtime, it's not saving, it's not doing anything, just the entity and the entity works with the repository. The repository could be related to a data table from a database or something like that, but it's not implementing the logic to save or to retrieve the information from the database. It's only an interface with defining what we need from the part that is in the attraction layer. And this part is also a business logic representation. It's not related to the current framework or the database that we are using. In this case for the customer, it's easy to see that it's only defined that we have, we need a function to get all the customers for a phone number, but it's not implementing. And the save that only is a declaration. And for the repository, it's part of the business logic, but not for the framework. With the repository, there is the implementation, that is this one. In this case, using Doctrine, in this case, he's defining how the data will be saved or retrieved or anything. And this one is dependent of the framework, but I think the advantage to the code is that if we need to change the database or the framework, we only have to implement this class. And that's all. We don't need to modify the business logic or the core logic. And the most important part is the services. This is the part where all the magic is, all the business logic is. I didn't include in this concept, but we are using in Symphony the events to communicate all these parts. So the service works with events to trigger actions. So if the service needs to save a customer, we'll just trigger an event. It's not calling directly the repository. With the events, dispatcher of the events, we are making this part independent of all the other parts. If there is not a repository interface to save the customer, no problem. The service will keep working, we'll just trigger the events and that's all. But it's not depending on the repository. That is event subscribers. This is how it looks. And we can see here that this triggering the events after a customer has been created. And how the service communicates with other services. And the other part that is not part of our logic but is part of the framework, the controllers and the view, this part is obviously part of the framework. We are depending on that. But it's only working as an interface to the user through the browser or API or anything. And just like a pass through from the input output and the services. That's all. We are not adding any logic here. Neither the controller or the view. This is the controller. One of the controllers. You can see that in this controller is calling or using the services. There is no logic about how it should be used. Only calling the service. The service will take care of the logic. So the first graphic that I made is a simplification of the entire stack. The current implementation is more complex. But in the end it's a simple graph. This is how the stack is done. It's more easy to see here how each part is independent of any other. We have the services. First of all, we have two models with two different services. This could be for customer or for store, for example, two different modules. Each one has a service that is independent of everything else. And it communicates every part through events. And we can see how this, the split between the parties framework dependent and our part that is only for the business logic. This is the approach that we took. We are still working on it. And we are spending almost two years on this. So we are evolving every day. But there is one thing that we use decoupling everywhere. Because it looks like nice and it's a good idea but it's not for every code. It could be abuse and it depends if the type of project, the size of the project, the size of the team. As with every tool or every technology that we have, we have to try to use the right tool for the right problem. And no use for every part. So we have to be smart to get with this or any other technology or big plastics or design pattern just to use it smart. And this is a conclusion that we have. This is not part of the decoupling. But there are some concepts that we can use full to decouple the code without implementing all the splitting in the code in the framework. And that's all. But it is like we should think each piece of code has more independence that we can. So it's not depending on any other. This way we can avoid a lot of problems with that. Of course, using design patterns. But again, it's not using design pattern in any part of the code or any piece of code. We should be smart to use where is needed. And one of the main concept that we throw is the layers or architecture. So it's like thinking of every part of the application in a level from the user to the database that will help to keep the code more clean and split. So mostly this is our experience working with decoupling and symphony. I hope that this is useful and informative. There is a lot of their concept that we can use to get into decoupling code. But the main objective is to have a project that can be updated and will be in good shape over the time. So thank you for the opportunity and thank you. I have some time for a couple of questions. Is it okay Miguel? Anyone have questions? Hello. You've mentioned about decoupling should not be used everywhere but for certain types of projects. So can you cite examples of projects that we can use decoupling efficiently? In our case we use it because our product will not change over the time mostly. But we need to keep adding features. We need to keep with the last technologies for frameworks and PHP version and that's all. So I think that this concept should be used in large projects mostly. Because all this separation of parts also is very useful to work in large teams. So we can split every part of code to a development group or developers. It depends on every project. I think that when you get the need to use you will know. But yeah, it's not a thing that I have this new project I will use. But on the other hand, it's like a set of best practices and ways to do the work that can be used in every project. For example, to follow the tree rules, the de-meter rules and the other tree rules. It's like a concept that we can use in any project and will be very useful to have a clean code and with all we're using all the technology that we have now for unit testing for deploying on the cloud and things like that. So I think that most of one only concept, I think that it's useful to take some parts of this and start using on any project. Any other questions? All right. Thank you Miguel. Thank you.