[0:00] okay so hi everybody I want to talk
[0:03] about my type of my pock is exactly
[0:06] teacher demystified so why this world
[0:09] demystified in the title why should it
[0:11] be kind of demystified well for me for a
[0:15] long time hexagonal architecture was
[0:17] kind of this mystical thing because
[0:19] whenever I start trying to learn
[0:21] something about it and there's no
[0:23] shortage of articles blog posts videos
[0:26] tutorials conference conferences people
[0:28] speak about it so there's a lot of
[0:30] resources but whenever I try to read
[0:33] something about it I would get over them
[0:35] pretty fast because all these articles
[0:38] they often talk about they would start
[0:40] talking about things like dv/dt d d pd d
[0:43] c ql c q RS ears comment and comment
[0:48] past pairs so yeah it was just too much
[0:51] for me to take and another problem is
[0:52] all these kind of articles they often
[0:54] kind of offer a slightly different view
[0:57] of what hexagonal architecture is so for
[1:00] me for a while for a long time i was
[1:02] never quite sure what hexagonal
[1:04] architecture is it was kind of mystical
[1:06] for me so my my goal for today is to
[1:08] kind of do for you what I did for myself
[1:11] and that is to simplify it or maybe even
[1:13] the world he still would maybe be a good
[1:16] choice of word for the title to distill
[1:18] this kind of clutter about around
[1:20] hexagonal architecture design in what it
[1:22] easy like what the original idea of
[1:24] hexagonal architecture is and then we
[1:26] can also see how we can kind of expand
[1:28] it and combine it with all this other
[1:30] architectural approaches that people
[1:32] often tend to do so before I start just
[1:35] a little bit about me my name is Juan
[1:37] Amir I come from Croatia but I've been
[1:39] living in Berlin for almost two years
[1:42] now this is my twitter handle if you if
[1:44] you wish to follow me on twitter and
[1:46] yeah i work at a company called made it
[1:49] love which is budget company but it's a
[1:52] remote force company so yeah I can I can
[1:55] barely care where I live alongside
[1:57] commit Michael Dauphin and I my tests
[2:00] are s so exact no architecture in 2005
[2:05] alistair cockburn
[2:06] published published an article called
[2:07] hexagonal architecture and then he later
[2:09] revisited and his
[2:11] that the name ports and adapters would
[2:13] be actually a better name for this
[2:15] architecture he said he believes it's
[2:18] it's a very description of the intent
[2:20] behind his architecture but it seems to
[2:23] me like the name hexagonal kind of
[2:25] people use it more often I guess it's
[2:26] just more cool cool name again it is the
[2:30] same thing those doctors allister's
[2:34] starts is article by saying it is a
[2:36] response to the discussion on the
[2:39] traditional layer architecture so this
[2:41] is how we got to start our tour by
[2:44] looking at layered architecture first so
[2:47] layered architecture states that in
[2:49] order for us to better to help ourselves
[2:53] with comprehending and dealing with
[2:54] software systems the complexity of our
[2:57] software systems we should divide them
[2:58] into distinct layers and the difference
[3:00] between layers is in the level of
[3:02] abstraction where these layers are going
[3:04] to result there's no limits to the
[3:06] number of layers and usually if you look
[3:08] at depending on the authors you are
[3:10] you're reading usually there's like
[3:12] three to four layers and here I'm going
[3:14] to use a four layered approach as it was
[3:16] explained in the brew DDD book by Eric
[3:19] currents so on the top of your stack of
[3:22] layers you have your user interface
[3:24] layer so this is the layer where users
[3:26] talk to your application this is kind of
[3:28] like the entry point to your application
[3:30] and also this is the layer way to show
[3:33] some data types or some data back to the
[3:35] user you communicate with the used below
[3:38] this layer you can give your application
[3:40] layer which orchestrates some domain
[3:43] objects in your domain layer to perform
[3:45] some action required by the end user and
[3:47] the domain layer it contains your domain
[3:49] objects your business logic is very very
[3:52] key results and then at the bottom of
[3:55] this layers stack you have your
[3:56] infrastructure infrastructure layer is
[3:58] there just two technical capabilities to
[4:01] support the upper layers so it's usually
[4:03] it's more it's about persisting a
[4:05] messaging right now the way the
[4:08] communication between this layer goes is
[4:10] you can only go downwards so layers can
[4:13] only talk two layers below them and here
[4:15] you have you can have two approaches one
[4:17] is the struct approach where a layer can
[4:18] only talk to the layer that is directly
[4:20] below within the stack and then there is
[4:22] like
[4:23] relaxed approach where a lair can talk
[4:26] to all the layers that are below in the
[4:28] stack so in this case the UI layer could
[4:30] directly talk to the infrastructure
[4:32] layer instead of going through like
[4:34] these all these others layers layers so
[4:36] you don't have to have this kind of
[4:37] proxy calls between an X now another way
[4:42] to look at these layers the way that we
[4:45] traditionally tend to think about them
[4:46] is to say that their user interface
[4:49] layer this is the front end of your
[4:50] application the infrastructure layer
[4:54] this is the back end and then this
[4:56] middle part I chose to call the core but
[4:58] you can also call it may be part of your
[5:00] software if you wish to be and more 20
[5:03] now then came Alistar in 2005 and he
[5:07] proposed a different look at the system
[5:10] so in our stars is in his view there is
[5:13] only two distinct parts to a system
[5:15] there is the inside world and then there
[5:18] is the outside world the inside world
[5:20] this is your core this is your
[5:21] application and everything else is the
[5:24] ink is the outside world so in this view
[5:26] the database and the web client are no
[5:30] longer back into front-end
[5:31] they're simply outside now as we know
[5:36] the outside world in this case our
[5:39] database and our web client they
[5:40] probably don't talk the same language as
[5:42] our core budget HP developers so our
[5:44] core folks HP while our web client talks
[5:47] HTTP and our database probably some
[5:49] flavor of SQL so in order for them to
[5:53] communicate to talk to each other we
[5:55] need this kind of transformer wrapper to
[5:58] Solon layer better they're going to
[6:00] wrapper another hexagon that is wrapping
[6:02] our core hexagon and in this XML what's
[6:04] going to happen is people are going to
[6:06] translate data from the or what the
[6:08] outside world can understand to the
[6:10] format that the inside world can
[6:11] understand so in this case we need to
[6:13] transform some HTTP requests into some
[6:16] PHP PHP data structure so a core can
[6:20] understand and also vice versa if our
[6:22] core needs to talk to the outside world
[6:23] it we need to transform this PHP PHP
[6:26] data structures probably some HP objects
[6:29] write to some to something that our
[6:31] outside world can understand in this
[6:32] case the web client can understand HTTP
[6:34] responses and
[6:36] singles with our database we need to
[6:37] somehow translate data between deserve
[6:39] my sink relational data and our hp8
[6:42] structures probably objects and this
[6:46] transformer wrapper this is where your
[6:49] adapters are going to live
[6:50] so this is where reports and afters
[6:52] coming to place into into plain this in
[6:55] this page so how does this work let's
[7:05] say in record you have written use case
[7:07] may be a registered user action it can
[7:11] be as simple as some kind of a service
[7:14] class that accepts some kind of hint
[7:16] right so you use case using the word use
[7:19] case here to be a bit more abstract but
[7:21] technically it can be it can be just a
[7:23] service class right in reality and this
[7:27] use case it defines kind of like an
[7:29] interface right it says if you want to
[7:31] register user you need to send me as
[7:33] with this data this is like the
[7:35] interfaces to the contract for talking
[7:37] to this your screen stand-in in the
[7:38] context of doctors architecture this is
[7:41] the point so your your core is defining
[7:43] a port of how you can talk to it now as
[7:46] we already mentioned our web client
[7:48] cannot directly access this sport
[7:51] because a web client talks HTTP and our
[7:54] interface for use case that is that
[7:56] space free right so what we now need is
[7:58] an adapter class and we have all written
[8:02] these kind of adapters a controller
[8:04] class right so what the controller class
[8:05] does is it takes the HTTP request
[8:07] transforms it into some PHP PHP data
[8:11] data structure again probably object and
[8:13] sends the passes that they type now in
[8:15] in this PHP data structure passes it to
[8:18] abuse case and vice versa if I use case
[8:22] needs to return some data the controller
[8:24] class can also transform it to HTTP
[8:26] response so now suppose that we need to
[8:28] support another way of talking to our
[8:30] application another way of kind of
[8:32] plugging into our use case may be a
[8:34] silicone mat right maybe we want our
[8:36] developers to be able to Association to
[8:38] the server and manually like here the
[8:40] CLI interface register users or maybe
[8:43] our clients are kind of factly and they
[8:45] also want like a CLI command to
[8:47] do these kind of actions so again we
[8:51] need an adapter class so we write and
[8:53] another another adapter now write the
[8:54] console command adapter which will take
[8:56] data from CLI input and again transform
[9:00] it to the same data structure and as it
[9:02] why your skis now there is an
[9:05] interesting thing here to note that is
[9:07] when we needed to add this new way of
[9:09] talking to our use case talking to our
[9:11] core we didn't have to touch the code in
[9:13] our core we only needed to write new
[9:15] code we only needed to write a new
[9:16] implementation you adapt you complete
[9:18] adapt so you see our core is kind of
[9:21] blissfully ignorant of all the different
[9:23] ways of talking to all the different
[9:24] methods talking to the earth to the core
[9:27] we are going to support so in future if
[9:29] we are going to maybe support maybe we
[9:31] were going to have some kind of rabbitmq
[9:34] then we proper implementer rabbitmq
[9:36] listener and after that will take data
[9:38] from the rabbitmq messages trust condom
[9:40] to PHP objects and pass them to are
[9:42] useless so you see our core our use case
[9:45] only cares about interfaces it only
[9:46] cares about a port and it says as long
[9:49] as you can plug something that obeys the
[9:51] sport something the pen talk to this
[9:53] port
[9:53] I don't care where this data comes from
[9:55] so this this kind of architecture has
[9:58] this kind of as the baked version call
[10:00] it potential for for timelessness why
[10:03] because you don't care in the future
[10:06] they can be many other many other ways
[10:09] of talking to application your colony on
[10:11] only cares about the ports so now you
[10:14] see why
[10:15] Alistair chose them when he revisited
[10:17] the article chose the name ports and
[10:19] adapters to describe this act
[10:20] architecture so this view we can say
[10:23] that our system is we can look at the
[10:25] system as kind of our core that is
[10:27] surrounded with interfaces to the
[10:29] outside world and the reason why I also
[10:32] chose to call it exactly why he chose to
[10:34] draw a hexagon I was actually quite
[10:37] simple because it was easier to draw
[10:39] than a Pentagon and yeah I'm not kidding
[10:42] he he really stated it but also be the
[10:44] disguise clean you get the same a notch
[10:46] with the Pentagon is easier to draw but
[10:48] you also get this analogy nice visual
[10:50] analogy where you can say that one edge
[10:53] of a hexagon represents one way of
[10:55] talking one reason
[10:57] application now as I already mentioned
[11:01] in this blue right picture there's only
[11:04] the east side role in jobs so it's
[11:08] already like this very symmetrical image
[11:10] where the database and the web trying to
[11:12] move on the back of the front end
[11:13] they're sitting outside outside so it's
[11:15] very symmetrical image but in time it is
[11:18] also a bit of an asymmetrical image so
[11:21] what I mean by this is that we can still
[11:23] kind of divide our ports into two
[11:25] distinct groups ports adapters and the
[11:28] way we are going to divide them is based
[11:29] on the way they communicate with the
[11:31] core so on the left side of this image
[11:33] and it doesn't have to be on the left
[11:35] side I just chose to draw it like this
[11:37] on the left side of the this image we
[11:39] have our primary ports called the dragon
[11:42] box and they're called the driving force
[11:44] because they are the ones who are
[11:45] initiating the communication with the
[11:47] core so they are kind of driving their
[11:49] behavior of our application usually our
[11:52] web client will say to our jorge do
[11:54] something for me or give me some data
[11:56] show something to me right it is it has
[11:58] this kind of active active role in
[12:00] communicate in communicating with all
[12:02] while on the other hand the driven ports
[12:04] or the secondary port so let's cannibal
[12:08] as supports when they communicate in the
[12:11] core it is our it is the core that
[12:13] initiates communication with them so the
[12:15] core will tell the database came
[12:17] give me some data or can persist some
[12:19] data for me so they have this kind of
[12:20] more passive passive role in this
[12:22] communication so that's why they called
[12:24] the driven or secondary ports so this is
[12:28] this is a business portal Aptus
[12:30] Architect reduces hexagonal architecture
[12:32] Alistair didn't mention any kind of
[12:35] general instructions on how you should
[12:37] actually structure your code inside the
[12:39] poor you didn't say that you can that
[12:42] you should use layers or and he also
[12:44] didn't say that you shouldn't use layers
[12:46] so what about layers right because a lot
[12:49] of people usually use layers con
[12:52] combined with examine architecture and a
[12:53] lot of people will say when you say
[12:55] example architecture all your layers and
[12:57] things are talking about layers right
[12:59] right away
[13:00] so yeah you can use you can combine
[13:02] Excel architecture with layers and but
[13:05] there's a there is a slightly it's like
[13:06] a subtle difference or maybe not so
[13:10] subtle between what you gonna have now
[13:13] with example architecture and layers and
[13:15] a traditional layered architecture so
[13:19] again we have our domain domain layer
[13:21] it's in our core right then we have this
[13:24] application layer that is kind of
[13:25] wrapping our our main layer and then the
[13:29] infrastructure and the user interface
[13:31] layer there they both live in this kind
[13:33] of transformer retro as we chose to call
[13:35] so as you see the difference between
[13:38] this and traditional layered
[13:39] architecture is that in traditional
[13:41] layered architecture we have like a
[13:42] stack of layers so layers were strike
[13:44] one on each other while he were here the
[13:47] layers are kind of like wrapping each
[13:48] other so it's more like a like like
[13:51] peeling an onion right like an onion and
[13:54] actually there is this thing called an
[13:56] onion architecture and this is very
[13:57] really similar to that this kind of
[13:59] formation of onion architecture and
[14:01] hexagonal architecture and this
[14:03] difference also means that let me talk
[14:05] about that communication between layers
[14:07] as you remember in traditional layered
[14:11] architecture the communication would go
[14:13] downwards while it goes inwards right
[14:16] because layers are wrapping each other
[14:17] so communication goes from the outside
[14:19] to the inside to the two towards our
[14:21] core and this row for communicate about
[14:23] communication well it only goes inwards
[14:26] this this applies this applies to
[14:28] several architectural even if you are
[14:30] not combining
[14:31] layers with okay so now that we know
[14:35] what the exact role of architecture is
[14:37] let's let's take a look at one example
[14:38] how we can actually implement it in PHP
[14:41] this is how I kind of usually go about
[14:43] it and also it's a combination of what I
[14:45] saw other people do it in in workshops
[14:48] and and some tutorials so we're gonna
[14:52] take a look at the driving side first so
[14:53] here I have a simple simple let's say
[14:57] I'm cooking cooking app so we have our
[15:00] recipes and we have some users if you're
[15:02] into DDD as you see I kind of have two
[15:06] bounded contacts here if you don't know
[15:08] what that means
[15:09] think of it like this everything related
[15:11] to a recipe will be in the recipe folder
[15:13] everything related to user will be in
[15:16] the user folder so it's kind of like two
[15:18] soft parts of your application two
[15:20] modules distinct modules in your
[15:21] application and I'm gonna have one
[15:24] hexagon for module one hexagon per
[15:26] bounded context here
[15:27] I didn't here I didn't choose to use
[15:30] layering but I did choose to put my
[15:33] infrastructure and my UI in different
[15:35] folders so I I did make distinction
[15:37] between primary portion and secondary
[15:39] ports or driving for George and German
[15:41] ports and then I have my mic or phone so
[15:47] one way of talking to my application is
[15:49] going to be bearish a bit so I have this
[15:51] great controller to create a recipe and
[15:54] in it on all that my controller does is
[15:58] it takes some HTTP data from HTTP
[16:00] request this is kind of simple it's
[16:02] simply like code and all it is to do is
[16:05] take this HTTP request take some data
[16:07] from it and pass transform the data to
[16:10] some PHP structure and pass it to our to
[16:12] our core and in our core we have this
[16:14] create recipe serves it is a very simple
[16:17] stories Here I am passing just this
[16:19] string primitive string value probably
[16:23] want to have something more robust like
[16:24] a data transfer object or that object or
[16:27] something like that and keeping it
[16:29] simple for that for the sake of this
[16:31] example and what is important here is
[16:33] not that we want to support another way
[16:35] of talking to our to our core of
[16:37] creating a recipe we are another way of
[16:39] talking to our application we just
[16:41] implement another adapter and here again
[16:44] the only difference is that now we take
[16:46] input from different source but we still
[16:48] just pass pass data to our to our great
[16:51] recipe
[16:51] service that still lives on our core and
[16:53] we didn't have to do any adjustments to
[16:56] the code of that lives in our core which
[16:58] is great recipe service we only added
[17:00] new code this new in concrete adapt and
[17:03] again our core really doesn't care if we
[17:05] are calling this service from from our
[17:08] CLI command or HTTP control right
[17:12] it is blissfully ignorant of the ways of
[17:15] talking to an application you are going
[17:16] to use so this is only driven on the
[17:19] driving side let's take a look look at
[17:22] the driven sir now and it is going to be
[17:24] a bit more complex but yeah it's it's
[17:27] but pay attention so on the German side
[17:31] we have our creators in the core we have
[17:32] our create recipe service this is our
[17:34] axle so is that kind of use case winner
[17:36] so again it's really simple all it does
[17:39] is it takes this input this string name
[17:42] of the recipe it creates the recipe
[17:43] entity and then it persisted by calling
[17:46] the same method on the dependency that
[17:48] it has and that is the recipes
[17:49] repository now if they were paying
[17:53] attention you realize that we have a bit
[17:55] of a problem here so we said that the
[17:57] dependencies are going inwards so as we
[17:59] see in this image the infrastructure can
[18:01] talk to the core but the core the core
[18:04] cannot talk directly to infrastructure
[18:05] core should be unaware of concrete
[18:08] infrastructure you are use and if you
[18:10] look at our code here
[18:11] our create recipe use case the great
[18:14] recipe service it is dependent on the
[18:17] recipes repository it is talking to it
[18:19] directly because it is a dependency and
[18:21] the recipes repository it lives in the
[18:24] infrastructure because it has some
[18:26] infrastructure related code to actually
[18:27] persist this end right so this is
[18:29] problematic because we are we are not
[18:30] violating this this rule of dependencies
[18:33] only going in bus so what can we what
[18:35] can we do about this well we can use
[18:38] something that is called inversion of
[18:40] control or people also call it the
[18:43] pendency version principle and again it
[18:46] sounds a bit scary but what it actually
[18:48] means as a rule of thumb what you need
[18:51] to do is when you have a situation like
[18:52] this is to introduce an abstraction
[18:55] usually an interface so what we're going
[18:58] to do now is we are going to introduce
[18:59] this interface so now the recipes
[19:02] repository we're going to introduce an
[19:04] interface for you and this interface is
[19:07] going to live in our code because this
[19:10] is a concept that belongs to our domain
[19:12] right
[19:12] saving recipes and patching them this is
[19:14] a concept that belongs to our court or
[19:17] domain so now our create recipes service
[19:19] is dependent on this recipes interface
[19:22] which lives in the core Andy this is
[19:24] okay right because they are born in the
[19:27] core so we are not probably think any
[19:29] any and dependencies here and our
[19:31] concrete implementation of this
[19:33] interface and sqlrepository that will
[19:36] actually persist this lives in the
[19:38] and it is also dependent on this
[19:41] interface but that is also okay because
[19:43] infrastructure core code can talk to our
[19:46] core it can be dependent on the code so
[19:48] we are now not violating any of those
[19:51] dependencies going inwards rule and this
[19:54] is what you see it's kind of like called
[19:56] dependency version because now you see
[19:58] dependencies are kind of inverse but
[20:01] yeah that's that's a bit of another
[20:02] story but this is how it is how you can
[20:05] kind of treat this trick to not not
[20:09] violate these dependencies rules and
[20:12] yeah our sqlrepository now have some SQL
[20:16] specific code here we are using doctrine
[20:18] or m to actual persist this persist this
[20:21] entity so now that we know what our
[20:26] exceptional architecture is how we can
[20:29] we know one will be shown one way of
[20:32] implementing it the question remains is
[20:34] why should we do it right
[20:35] are there what are the benefits of
[20:37] developing your applications this way
[20:40] well the first big benefit is that it
[20:43] allows you to delay technical decisions
[20:45] so why would this be important why would
[20:48] we want to delay technical decisions
[20:50] well if you think about it there is a
[20:52] certain paradox to how we develop
[20:54] software how we will work on our
[20:55] projects and that is at the beginning of
[20:57] our project where a project knowledge is
[20:59] at the minimum because it's always going
[21:01] to like with time your project nor with
[21:03] knowledge is only only going to grow so
[21:05] at the beginning beginning it's always
[21:07] at the minimum point and this minimum
[21:09] point we are making big decisions on the
[21:12] technical decisions on what technology
[21:14] we are going to use so wouldn't it be
[21:16] nice if we could delay these technical
[21:18] decisions to some point in time where
[21:20] our project knowledge will be at the
[21:22] bigger point and then we can make a much
[21:24] more informed choice of the hold key we
[21:26] are going to use and hexagonal
[21:28] architecture allows us to do just this
[21:31] so for example maybe you are not sure in
[21:34] your in your project you're starting
[21:35] your new project maybe you're not sure
[21:37] do you want to use a sequel database or
[21:39] a no sequel database so what you can do
[21:42] is you can help us recipes your
[21:45] repositories interfaces you introduce
[21:47] interfaces for your repositories and
[21:49] then you have this concrete
[21:50] implementation
[21:51] interpretations of these repositories
[21:53] these interfaces and you can implement
[21:56] them in plain PHP it can be as simple as
[21:59] they just take your entity they
[22:00] serialize it and save it to some text
[22:03] file now this is not something you want
[22:05] to push the production obviously but it
[22:07] will work it'll it will work you will be
[22:09] able to develop your domain play around
[22:11] with it model it even write test for it
[22:14] and then when you are when you have some
[22:16] more knowledge when your lecture more
[22:19] sure what college you wanna use then
[22:21] maybe you say okay now I'm going to use
[22:22] my sequel database at that point all you
[22:24] need to do is I mean call it look you
[22:27] need to do only only thing you need to
[22:28] do easy from any new adapters now
[22:31] they're gonna really persist to to my
[22:34] sequel database and then you just plug
[22:36] those adapters instead of those naive
[22:37] PHP ones and everything still works
[22:39] right another thing about this is
[22:42] exactly architecture allows us to even
[22:45] when we make these decisions we can
[22:47] still kind of change our mind
[22:48] right so we can swap technologies
[22:50] relatively easy right so say we said
[22:53] okay we're gonna use my signal and then
[22:55] for some reason later in the project we
[22:58] say oh now we want to switch to post
[23:00] cast on it so again only thing you need
[23:02] to do is write new adapters and of
[23:05] course writing your adapters can still
[23:07] be a lot of work but you don't have to
[23:08] touch any existing code again you don't
[23:11] have to touch any code in your core you
[23:13] don't have to make any adjustments in
[23:15] your core in your domain only thing your
[23:17] only thing you need to do is and you
[23:19] want a new adapters right some
[23:21] integration tests for them and once
[23:23] you're sure that is the latter's work
[23:24] you just plug them in instead of those
[23:26] my cheap ones and you're good to go
[23:28] everything still works as no and you can
[23:31] swap these technologies like do this for
[23:34] every technology you are use this is my
[23:36] kind of link has this potential for
[23:37] timelessness examine architecture
[23:40] another thing like excitement
[23:42] I like hexagonal architecture and why I
[23:44] think it's so popular in the dimension
[23:46] design community is that it really does
[23:49] allow you to really focus on the core
[23:51] and developing your application so your
[23:53] core your domain can really be domain
[23:54] driven instead of kind of technology
[23:56] driven now of course it is maybe a bit
[23:59] more idealistic to think that you can
[24:01] really model your core without any
[24:03] influence from the
[24:04] infrastructure from the technologies you
[24:06] are going to use but still it does allow
[24:08] you to really focus and not not think
[24:10] about technologies you won't use too
[24:12] much which is I guess why it's real
[24:15] popular in the DDD community and another
[24:18] big thing for about architecture
[24:21] actually one of the big motivations for
[24:22] Alistair to kind of start thinking about
[24:24] it is testability so when it comes to
[24:26] testability on the drive inside what you
[24:29] can do is you can replace your real
[24:31] adapters with test adapters and test
[24:34] enough actors in this context this is
[24:36] your your your testing shoot right and
[24:39] maybe you can have like this nice set of
[24:41] BDD start s with P head there is where
[24:44] you can just yeah plug them in and test
[24:47] your test your use cases test your you
[24:49] have your acceptance test like this so
[24:52] you can really test your application in
[24:54] isolation and you don't have to go test
[24:58] your application by going through the UI
[24:59] you can just plug in this test instead
[25:02] of your UI and and test your code direct
[25:04] and when it comes to the drill site to
[25:08] the secondary infrastructure again you
[25:11] can replace your test infrastructure
[25:13] with some kind of you can replace your
[25:15] real our infrastructure is some kind of
[25:17] test infrastructure sold again let's say
[25:19] maybe maybe you are talking to some
[25:21] cloud provider or whatever you can again
[25:24] create these adapters that will just
[25:26] needs a kind of PHP implementation but
[25:28] you will just check if this is calls are
[25:31] getting true and this is this will help
[25:34] you because not really tester you can
[25:37] test your own in isolation and your
[25:39] tests are going to be much faster
[25:40] because now you have to test time in the
[25:43] real infrastructure now don't get me
[25:46] wrong you will still have your set of
[25:47] integration tests for your real adapters
[25:50] but when you are testing your core what
[25:52] you want to do is you want to test your
[25:53] business logic inside your core you
[25:55] don't want to every time you're testing
[25:57] certain a certain business case in your
[25:59] core you don't really want want it to
[26:01] ping the real infrastructure because you
[26:03] don't we need to retest this integration
[26:05] with real infrastructure
[26:06] every time you are testing every single
[26:08] business case in your domain this is why
[26:10] you can give this you can switch it with
[26:13] some testing infrastructure so your
[26:14] tests are gonna but so your test when
[26:16] you're testing your core it's work
[26:18] gonna run much faster and then you have
[26:20] a separate set of integration tests to
[26:23] really test your adapters to make sure
[26:25] that this integration also will work
[26:28] okay then finally the the final question
[26:32] to answer is when you actually use
[26:34] exactly no architecture because some
[26:37] people I mean one thing that that is
[26:40] true exactly larger exact architecture
[26:44] like every architecture course adds a
[26:46] complexity to your code right and as I
[26:48] say as every architecture because every
[26:50] every design pattern they all add some
[26:52] complexity right and the question for me
[26:55] here is not not that I should we should
[26:59] should we add this more complexity but
[27:02] the question is does it pay off
[27:03] right because the reason why we have
[27:05] design patterns and and hire anyone like
[27:08] higher higher languages is because we as
[27:10] humans have a problem with grasping the
[27:13] complexity of a computer right a
[27:15] computer doesn't really care you can you
[27:17] can write your application in binary in
[27:19] machine code right people used to do
[27:22] that but you cannot write write it now
[27:24] like a boom your complex application
[27:25] this is why we can you know these nice
[27:27] languages and then we get these design
[27:29] patterns and all that stuff and
[27:30] architectures to help ourselves to grasp
[27:33] the complexity of our programs so I
[27:36] would say that if the if your domain is
[27:39] compact X enough and you think that you
[27:41] will gain the benefit of this little
[27:43] added complexity by using a certain
[27:45] architectural approach like cell
[27:47] architecture then I would say you should
[27:49] use it and it will pay off so the real
[27:51] question is does it does it pay off and
[27:54] that was it thank you for your attention
[27:56] and if you have any questions I believe
[27:59] we we do have some time for questions