2020 06 Zvonimir Spajic - Hexagonal Architecture Demystified

[00:00] okay so hi everybody I want to talk

[00:03] about my type of my pock is exactly

[00:06] teacher demystified so why this world

[00:09] demystified in the title why should it

[00:11] be kind of demystified well for me for a

[00:15] long time hexagonal architecture was

[00:17] kind of this mystical thing because

[00:19] whenever I start trying to learn

[00:21] something about it and there's no

[00:23] shortage of articles blog posts videos

[00:26] tutorials conference conferences people

[00:28] speak about it so there's a lot of

[00:30] resources but whenever I try to read

[00:33] something about it I would get over them

[00:35] pretty fast because all these articles

[00:38] they often talk about they would start

[00:40] talking about things like dv/dt d d pd d

[00:43] c ql c q RS ears comment and comment

[00:48] past pairs so yeah it was just too much

[00:51] for me to take and another problem is

[00:52] all these kind of articles they often

[00:54] kind of offer a slightly different view

[00:57] of what hexagonal architecture is so for

[01:00] me for a while for a long time i was

[01:02] never quite sure what hexagonal

[01:04] architecture is it was kind of mystical

[01:06] for me so my my goal for today is to

[01:08] kind of do for you what I did for myself

[01:11] and that is to simplify it or maybe even

[01:13] the world he still would maybe be a good

[01:16] choice of word for the title to distill

[01:18] this kind of clutter about around

[01:20] hexagonal architecture design in what it

[01:22] easy like what the original idea of

[01:24] hexagonal architecture is and then we

[01:26] can also see how we can kind of expand

[01:28] it and combine it with all this other

[01:30] architectural approaches that people

[01:32] often tend to do so before I start just

[01:35] a little bit about me my name is Juan

[01:37] Amir I come from Croatia but I've been

[01:39] living in Berlin for almost two years

[01:42] now this is my twitter handle if you if

[01:44] you wish to follow me on twitter and

[01:46] yeah i work at a company called made it

[01:49] love which is budget company but it's a

[01:52] remote force company so yeah I can I can

[01:55] barely care where I live alongside

[01:57] commit Michael Dauphin and I my tests

[02:00] are s so exact no architecture in 2005

[02:05] alistair cockburn

[02:06] published published an article called

[02:07] hexagonal architecture and then he later

[02:09] revisited and his

[02:11] that the name ports and adapters would

[02:13] be actually a better name for this

[02:15] architecture he said he believes it's

[02:18] it's a very description of the intent

[02:20] behind his architecture but it seems to

[02:23] me like the name hexagonal kind of

[02:25] people use it more often I guess it's

[02:26] just more cool cool name again it is the

[02:30] same thing those doctors allister's

[02:34] starts is article by saying it is a

[02:36] response to the discussion on the

[02:39] traditional layer architecture so this

[02:41] is how we got to start our tour by

[02:44] looking at layered architecture first so

[02:47] layered architecture states that in

[02:49] order for us to better to help ourselves

[02:53] with comprehending and dealing with

[02:54] software systems the complexity of our

[02:57] software systems we should divide them

[02:58] into distinct layers and the difference

[03:00] between layers is in the level of

[03:02] abstraction where these layers are going

[03:04] to result there's no limits to the

[03:06] number of layers and usually if you look

[03:08] at depending on the authors you are

[03:10] you're reading usually there's like

[03:12] three to four layers and here I'm going

[03:14] to use a four layered approach as it was

[03:16] explained in the brew DDD book by Eric

[03:19] currents so on the top of your stack of

[03:22] layers you have your user interface

[03:24] layer so this is the layer where users

[03:26] talk to your application this is kind of

[03:28] like the entry point to your application

[03:30] and also this is the layer way to show

[03:33] some data types or some data back to the

[03:35] user you communicate with the used below

[03:38] this layer you can give your application

[03:40] layer which orchestrates some domain

[03:43] objects in your domain layer to perform

[03:45] some action required by the end user and

[03:47] the domain layer it contains your domain

[03:49] objects your business logic is very very

[03:52] key results and then at the bottom of

[03:55] this layers stack you have your

[03:56] infrastructure infrastructure layer is

[03:58] there just two technical capabilities to

[04:01] support the upper layers so it's usually

[04:03] it's more it's about persisting a

[04:05] messaging right now the way the

[04:08] communication between this layer goes is

[04:10] you can only go downwards so layers can

[04:13] only talk two layers below them and here

[04:15] you have you can have two approaches one

[04:17] is the struct approach where a layer can

[04:18] only talk to the layer that is directly

[04:20] below within the stack and then there is

[04:22] like

[04:23] relaxed approach where a lair can talk

[04:26] to all the layers that are below in the

[04:28] stack so in this case the UI layer could

[04:30] directly talk to the infrastructure

[04:32] layer instead of going through like

[04:34] these all these others layers layers so

[04:36] you don't have to have this kind of

[04:37] proxy calls between an X now another way

[04:42] to look at these layers the way that we

[04:45] traditionally tend to think about them

[04:46] is to say that their user interface

[04:49] layer this is the front end of your

[04:50] application the infrastructure layer

[04:54] this is the back end and then this

[04:56] middle part I chose to call the core but

[04:58] you can also call it may be part of your

[05:00] software if you wish to be and more 20

[05:03] now then came Alistar in 2005 and he

[05:07] proposed a different look at the system

[05:10] so in our stars is in his view there is

[05:13] only two distinct parts to a system

[05:15] there is the inside world and then there

[05:18] is the outside world the inside world

[05:20] this is your core this is your

[05:21] application and everything else is the

[05:24] ink is the outside world so in this view

[05:26] the database and the web client are no

[05:30] longer back into front-end

[05:31] they're simply outside now as we know

[05:36] the outside world in this case our

[05:39] database and our web client they

[05:40] probably don't talk the same language as

[05:42] our core budget HP developers so our

[05:44] core folks HP while our web client talks

[05:47] HTTP and our database probably some

[05:49] flavor of SQL so in order for them to

[05:53] communicate to talk to each other we

[05:55] need this kind of transformer wrapper to

[05:58] Solon layer better they're going to

[06:00] wrapper another hexagon that is wrapping

[06:02] our core hexagon and in this XML what's

[06:04] going to happen is people are going to

[06:06] translate data from the or what the

[06:08] outside world can understand to the

[06:10] format that the inside world can

[06:11] understand so in this case we need to

[06:13] transform some HTTP requests into some

[06:16] PHP PHP data structure so a core can

[06:20] understand and also vice versa if our

[06:22] core needs to talk to the outside world

[06:23] it we need to transform this PHP PHP

[06:26] data structures probably some HP objects

[06:29] write to some to something that our

[06:31] outside world can understand in this

[06:32] case the web client can understand HTTP

[06:34] responses and

[06:36] singles with our database we need to

[06:37] somehow translate data between deserve

[06:39] my sink relational data and our hp8

[06:42] structures probably objects and this

[06:46] transformer wrapper this is where your

[06:49] adapters are going to live

[06:50] so this is where reports and afters

[06:52] coming to place into into plain this in

[06:55] this page so how does this work let's

[07:05] say in record you have written use case

[07:07] may be a registered user action it can

[07:11] be as simple as some kind of a service

[07:14] class that accepts some kind of hint

[07:16] right so you use case using the word use

[07:19] case here to be a bit more abstract but

[07:21] technically it can be it can be just a

[07:23] service class right in reality and this

[07:27] use case it defines kind of like an

[07:29] interface right it says if you want to

[07:31] register user you need to send me as

[07:33] with this data this is like the

[07:35] interfaces to the contract for talking

[07:37] to this your screen stand-in in the

[07:38] context of doctors architecture this is

[07:41] the point so your your core is defining

[07:43] a port of how you can talk to it now as

[07:46] we already mentioned our web client

[07:48] cannot directly access this sport

[07:51] because a web client talks HTTP and our

[07:54] interface for use case that is that

[07:56] space free right so what we now need is

[07:58] an adapter class and we have all written

[08:02] these kind of adapters a controller

[08:04] class right so what the controller class

[08:05] does is it takes the HTTP request

[08:07] transforms it into some PHP PHP data

[08:11] data structure again probably object and

[08:13] sends the passes that they type now in

[08:15] in this PHP data structure passes it to

[08:18] abuse case and vice versa if I use case

[08:22] needs to return some data the controller

[08:24] class can also transform it to HTTP

[08:26] response so now suppose that we need to

[08:28] support another way of talking to our

[08:30] application another way of kind of

[08:32] plugging into our use case may be a

[08:34] silicone mat right maybe we want our

[08:36] developers to be able to Association to

[08:38] the server and manually like here the

[08:40] CLI interface register users or maybe

[08:43] our clients are kind of factly and they

[08:45] also want like a CLI command to

[08:47] do these kind of actions so again we

[08:51] need an adapter class so we write and

[08:53] another another adapter now write the

[08:54] console command adapter which will take

[08:56] data from CLI input and again transform

[09:00] it to the same data structure and as it

[09:02] why your skis now there is an

[09:05] interesting thing here to note that is

[09:07] when we needed to add this new way of

[09:09] talking to our use case talking to our

[09:11] core we didn't have to touch the code in

[09:13] our core we only needed to write new

[09:15] code we only needed to write a new

[09:16] implementation you adapt you complete

[09:18] adapt so you see our core is kind of

[09:21] blissfully ignorant of all the different

[09:23] ways of talking to all the different

[09:24] methods talking to the earth to the core

[09:27] we are going to support so in future if

[09:29] we are going to maybe support maybe we

[09:31] were going to have some kind of rabbitmq

[09:34] then we proper implementer rabbitmq

[09:36] listener and after that will take data

[09:38] from the rabbitmq messages trust condom

[09:40] to PHP objects and pass them to are

[09:42] useless so you see our core our use case

[09:45] only cares about interfaces it only

[09:46] cares about a port and it says as long

[09:49] as you can plug something that obeys the

[09:51] sport something the pen talk to this

[09:53] port

[09:53] I don't care where this data comes from

[09:55] so this this kind of architecture has

[09: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