Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
so thanks again I'm happy to be here again I loved being here last year and I was praying to be accepted as a speaker again so thank you very much and also thank you for being here this is more or less related to what I talked about last year was the subject
was then the naked bundle I changed some ideas and well this is again about framework decoupling but it's more or less not fighting frameworks but more like embracing frameworks in the right places in your application so it's going to be about this
nice little shape well you will learn all about it of course but it's just just as a teaser for what this is about you might ask yourself architecture and I mean the title of this talk is hexagonal architecture you might be wondering what's wrong with
any kind of other architecture why do I need to have a hexagonal architecture well so let me answer the problem or answer this question by explaining the problem with what's going on in application development these days a lot so first of all we start
out working on a nice application it's it's still pretty small you may be the only one working on it and you have some great ideas on how to structure this thing but then people come into your team and maybe you leave your team there may be different
ideas in the same application and suddenly or people start pulling in extra dependencies calling all kinds of things using all kinds of new interesting servers or services next to your application and then it becomes something like this what was a nice app
becomes a pretty sad app and that's because of all the dependencies all the arrows going in every in any kind of a direction so people usually start to find some ordering principle right so you can make sense of this anymore so you need some guidelines
for structuring or structuring your application and usually there are three ways in which people structure their code they put things together that are more or less alike in function basically so we put things related to the domain model inside a directory
called model or if you use doctrine entities right and then you put everything really - views like templates or maybe assets in some directory called views possibly and what's left is to see of course for controllers everything that that is that looks
like a controller or behaves like a controller you put in the same directory so first of all there are so many other things that that wouldn't fit into this model but I guess in general you could say that this is mainly insufficient to serve as an architectural
design principle for your application so I'd say MVC well not really quite sufficient as a guideline for designing your applications but brenda's all this MVC thing thinking come from well basically from all the frameworks out there and this is not
to say that frameworks are a bad thing just as I as I said before they're good in particular areas of your application but again well MVC is more or less coupling to a framework as in you take their approach to software development as the way to go for
your own project as well this is very apparent if you look at the way that people approach creating projects or starting new projects so what do you do you pick a framework basically you install some get up repository or create a project install a skeleton
project maybe then remove all the stuff that is not relevant to your project the demo demo stuff or the the boilerplate configuration that you don't need then you start auto generating stuff like entities or controllers or I don't know anything you
can also generate and then you're done you can quickly develop some application and some people will be happy about it and then you say well we're working on a simply project for example but that might as well be a laravel project or any project at
all to me that's actually outside in you could say that all of these choices about well the framework or the particular type of database that you're going to use or the messaging server that you like this is pretty much boring stuff what's interesting
is is hidden a little bit deeper in your application so I will show you what that is but for now I'll leave it at this starting with all the technological technological choices and or in fact determining your technology stack for the for the project brings
you a lot of slow and this is actually very nice Karen talked about this this morning where if you if you test the application you will notice that you need all kinds of other things to be available while running the tests like the database or file system
there has to be some directories there's to be some files maybe you even need to have an actual running message server or a message queue things like that so setting all these things up is slow talking to all these things is slow as well so your test suite
is likely to become minutes maybe even hours I hope not but the question may arise why do frameworks not solve this for us well it's because they can't and this is something well I mean we can fight frameworks or at least I did in the past but I stopped
doing this because well I I was blaming them for the wrong kind of issues because frameworks are all about encapsulation just like like symphony and and doctrine they they all try to hide some low-level details from our site so we don't have to worry about
things we don't have to remember how to do these things we just learned from Benjamin that it's not really true you always have to know about the details behind what's what's going on and those nice api's but then again you can compare
the code like like this to get the request body of of an HTTP request find out the content type of the request and then decode it somehow all this this low-level detail stuff is nowadays wrapped behind all these nice higher-level interfaces like serialize
and deserialize and then there's a request object you can ask the content type right away you don't need to handle all those those those details anymore and the same goes for talking to our databases so we used to do things like this well if you didn't
use my SQL underscore query functions but if you use PDO then something like this would actually fetch data from the database and instantiate some in this case patient objects but this is still quite low level you can actually see the SQL query or more what
the one that will be sent to the server and you need to remember all those steps like about hydration and the order in which the methods should be called so libraries like doctrine they hide this thing from site and they offer you nice little fluent functions
as well to to do the same thing but not to worry about all those details anymore but that is I'm sorry that's encapsulation and what's missing is is abstraction we need this to mint to structure our applications in a better way because looking
at the same example again all these things are very concrete still they are they are words coming from the language in which we speak about databases and talking to databases so that is why this is concrete and the code is still about communicating with the
database it's about queries it's about matching fields getting the actual query and getting the result from that what is more abstract would be to zoom out a bit and look at the database maybe as a collection of objects so then we have invented the
word repository to represent a collection of in this case patient objects and we can just ask it for all the anonymous patients and suddenly we are not in the language of talking to database anymore so this is true abstraction we don't see anything about
[ ... ]
Nota: se han omitido las otras 3.759 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.