Understanding Hexagonal Architecture: Transforming MVC Applications

so welcome everyone uh today we're starting with our first live streaming series uh focusing on Hex School

architecture the why so essentially to get a better understanding of what is the purpose behind the hexagonal

architecture why do we use uh architecture how can we even

transform our project which was let's say maybe an MVC application into hexagonal architecture and why should we

even do that so I do want to say that this session will be interactive

so this means you'll be able to ask comments in chat in live chat at any time so as I'm drawing through the

um a sample project I will also be periodically looking at comments and essentially trying to answer them uh at

real time as much as possible so I'm really looking forward to hearing from you

and also just before we get started there's also some further additional reference material which you can look at

later if you want to learn more about hexagon architecture but now let's get right into it

so I'm sharing my Miro screen I hope that everyone can see it feel free to write any comments in in chat I hope

that the font and everything else is fine so let's get uh started with the uh actual

scenario that we have here so we were software there's a development team Within

uh pizza shop company and up to now they were doing all of their Pizza ordering via phone and via email and now they've

decided to actually build an eShop so that they can sell pizzas online and as part of the requirements we have

some simple requirements initially uh we want to make a system whereby the customers can browse pizzas can order

pizzas and can also order cancel orders also here is just some notation that I'll be using throughout uh the project

here throughout these diagrams so the first version that the development

team develops is a very typical MVC application this means we have a user like the customers

who will be accessing the MVC application and the MVC application will essentially

contain everything the views the business Logic the data access and here we are accessing

the database now what happens is that over time

we have certain challenges that are occurring so there is essentially

[Applause] uh more more and more business logic sorry

I seem to have a connection issue so I'm just retrying again okay so we have increasing

requirements and essentially complex business logic and it's taking longer and longer to

test [Applause] I mean manual testing takes uh a longer

time so then the team is trying to solve this problem and they get the idea that

perhaps they should introduce automated tests so in the next version of the

system we're going to be introducing automated tests

and these automated tests will be calling the MVC application okay so let's see what what we've

improved upon here so the automated tests help

reduce manual uh testing time okay great um

so let's see what what happens uh next again we get the problem that there are there again increases in

business requirements again business complexity the problem is

that there are more and more test cases [Applause]

but these automated pests which were initially uh quite fast I mean they are calling the UI but now they get slower

and slower simply because there's so many test cases in these UI tests which are in selenium or Cyprus are

essentially slow to execute and also since they are using the same database it means that we need to have

you know a tear down between each of the tests and again all of this is contributing to

an increased uh test run time and the question of the team asks us is

asking themselves is does it really make sense that we are testing all of these

different kinds of business logic through the UI

can we perhaps test the business logic separately not through the UI

and that way maybe we could help keep you know the separation between the UI and the business logic

this is when the team realizes that perhaps they should move to the standard free uh layer architecture

whereby they're going to have essentially the MVC app so

we're going to have some kind of uh views controllers news so this is the part

that that's handling the whole uh UI part let me just fix the spelling so the UI

and Below we have the business logic and we have the database access and this is probably the most common

architecture that many development teams are currently using around the world

right now and indeed the whole purpose of this live streaming session is to show how

and why we're going to move from this later to hexagonal architecture what what

problems does it solve and we will be going through the problems uh one by one

so since the team has introduced this kind of layering

it also means that they are able to have tests so if some tests still do remain in terms of calling the UI but uh

certain tests you can call the business logic directly

so we've achieved a very uh important Point here is that we have achieved test speed up

because business logic tests so business uh logic tests

are executed directly not through UI okay great everyone is is really happy about this

uh also so the questions are uh are there any other uh problems with this kind of architecture

well not yet at least it's not yet visible to the team but let's say we end up with a next

business requirement so the business requirement is some

third-party system wants to call our Bishop so as we mentioned we are making a pizza

e-shop but there's another really really big uh global company and they are essentially they have their

own e-commerce website and they are selling various kind of food to customers

so they could be selling lunches dinners desserts Etc and additionally they would like to sell pizzas so they've reached

out to a pizza shop company and they said you know we'd like you to become one of our pizza suppliers

can we integrate with your system so that when our customers make orders for pizzas that it can go into your system

and here we see the question is how exactly will that be executed so I'm just going to get the

symbol for the external system and we're going to need to use it in the next iteration

of our diagram but we have not big company

and they want to integrate with us the question is how will they integrate with us

uh can they call our UI well they say they don't want to do that they don't want their employees clicking on

our UI instead they want a system to system communication so this idea is not going to work

then the next idea is can they maybe execute our business logic that would mean that we would have to send them out

dlls or assemblies well no we we don't want to do that either

so the solution in that case is that we agree with them that perhaps we will be communicating via

let's say some kind of service maybe it's going to be soap or rest or something so for now I'm

just going to say that we agree that it's going to be a rest API so that means the communication is there's a

rest API here and the dot rest API is calling our business logic and here I'm just going

to rearrange the diagram just so that we can better uh see all this so we have

the users we have the tests which are still targeting our mvcf but we also have this new rest API which is

currently being used by um the third party essentially the website

who are following our system in in this way okay uh great thing so we've now

essentially introduced the rest API [Applause] best API

to enable for third party systems to communicate with us

and that rest API is delegating to business logic later there are some other companies as

well who want to interface with us but they don't want to interface via rest they have some older systems and they

actually prefer to use Swipe so this means that we're going to have to have some soap

apis as well [Applause] so some kind of soak service

that will be used by others okay the ques the next question that arises

is okay and this web service is is also calling our business logic

the next problem that we're faced with is how do we know that this you know soap API is working sorry the rest API

is working or is our soap service working do we just ship it to the third party

system and let them test or perhaps we should be doing the testing so we also should be introducing automated

tests uh there as well which test for example the rest API endpoints and just make sure

but we have the right uh connectivity I like the question so I'm already seeing some uh questions so

in chat so hello sorry

yep hello and who you who still uses sniper I like that question uh not not that many people but there are still

some companies who are using soap and even some companies who are using FTP or various other kinds of really really old

styles of communication and this is another reason why why it's really important to have this kind of

Separation so that regardless of which protocols or something is is chosen that that we can support it

yeah and again I do want to encourage everyone feel free at any point to write

any additional comments or or uh questions in chat and if you've had any experiences with this as well feel free

uh to add anything so let's continue on so

now that we have this uh the next uh challenge that is also uh occurring

is that our team is realizing that the MVC app

is not user friendly [Applause] into server side

exploding whereby like the whole page is loaded but instead they would prefer

to use uh to make a react application for example so let's see how are we going to do that

for our team is going to be making some kind of a react application and let's see where it's going to go so

uh react app would connect to our rest API so there we go the problem solved this is our own internal react

application connecting to our Presta API great but now let's see what else is happening

notice here how we have rest API soap service and we're still maintaining our old MVC up because the react app is not

not yet finished so we have all of these ones and they are referencing business logic

now be this business logic is again getting more and more complex and sometimes developers are

accidentally referencing too many details from the business logic layer so let's let's look at that problem

accidentally referencing business logic because

from the UI because from the rest API so and from MVC app controllers

the reason why this is possible is because each of these they have full you know reference to the business logic

layer so this means they can directly call whatever they want you know the order entity the customer entity can

invoke absolutely any methods there is zero control and what happens is that then developers even start writing if

else statements and various other kind of logic this layer

so business logic somehow is no longer just here but it starts being spread out here and here and here and these ones

the best API Philip service MVC app themselves become possibly inconsistent

so the question is do we really want all of these to directly reference our

entire anything from our business logic or perhaps do we want to restrict the access

so I'm just going to make this a bit smaller and let's see if we can restrict access

to our business logic but not everyone can do anything that they want

and here I'm going to be introducing some kind of an interface

so I will label it in this way and let me just move this down so that we have space

okay so what's going to happen is that essentially all of these will be

referencing some kind of API so this is some

user side sorry I'll call it the ordering API

so this one will essentially expose the key methods that we can browse pizzas that we can order pizzas

that we can cancel pizzas and that's it it's very very minimalist and our business logic we will Implement

whatever is required by that API okay the point here is that this the

presentation here can no longer access anything from business logic they are restricted to

what is provided by this interface so very

so I would say clear separation between you know the presentation Express API so

can we see up and business logic and it separated due to the

API okay great so we've already made an achievement and let's uh look at some

other comments so yeah FTP I like this comment I'm also going to add this into the

um diagram I know it's getting bigger but let's see how this drawing is is going to go maybe I will put it

somewhere at the end that uh another company contacts us they want to

interface with us and they have a really really Legacy system so they actually require us to communicate via FTP

they're going to send us files and we need some kind of FTP server no problem we can do that

for this there they are you know they're sending it and we can also write automated tests

targeting our fpp server as well so thanks for that time I really like it that we can improve the diagram in this

way together um okay yes so that's an example that we can

integrate even with with Legacy applications so is this going to be recorded and

available later yes it is being recorded immediately uh right now the only difference is availability of chat so if

you want to ask questions or make comments basically it's via chat uh right now but you can if you watch it

later as well I like this there are some banking course services that use soil

communication that that is exactly exactly correct so soap is is still used and this is yet another argument

why we need to have this kind of modularity in our architecture that that we are not

coupled neither to rest or soap maybe we could even have graphql or anything else

okay shouldn't the business logic tests attached to the API to excellent uh this

this is a really great comment uh as we can see in my previous diagram uh the tests were targeting the business logic

layer directly here since we introduced this ordering API here right now I'm glad that you pointed that

out then our tests will actually be calling our ordering API and if we look at this image here

we can see that our tests are at exactly the same level as the rest API as the swipe Etc

so they are all actually interacting with the business logic strictly through the API so that's an excellent one

thanks thanks for that so I updated the diagram now okay great we did a lot of improvements

now so um I know that this diagram is now

becoming much uh harder to manage for purposes of going further I'm just going to reduce it uh in in scope above just

for purposes of growing so I'm going to delete the the soap the rest API and I'm going to delete the FTP and let's just

have these two is is enough and we're going to continue on uh below but as you've seen you could have

however many you wanted of these you know presentations essentially so the question is what problems do we

uh encounter next up to now you've seen we've just been focusing on this uh side above

we weren't really focusing on this other side below which is the whole database access and as we know databases

do you tend to be okay really important as well now

there were some challenges that occurred uh our data access

was using orm and we needed to upgrade the orm this caused breaking changes everywhere

so since our business logic was dependent on the data database access it means the business logic was using the

orm entities and orm repositories everywhere and upgrading the orm would cause so many Breaking changes

uh to our business logic code and this is actually not a made-up story this is something that I've also personally

witnessed um in a real life situation with a team so let's see uh what's going to happen

next okay um

having a bit of issues again sorry with the connection should I so let's continue on

but that was not the only scenario that occurred uh team decided to change orm or switch to micro

uh orm because the current orm was maybe too heavyweight they weren't satisfied with the queries generated by the orm so

they wanted to maybe write SQL themselves or even uh

deciding to um deciding to switch to a different

database so maybe they were initially using postgres but then they had some

discussion and realize that perhaps mongodb would be a better choice or we also could have the situation that

um the database server was unavailable for whatever reason

[Applause] so let's say the database server on the test system was unavailable and all

testing was was blocked or something like that so we can see here

a lot of problems which are all stemming just because of the fact that our business logic is directly uh coupled

through the database and any of these changes for example these breaking changes it would mean

that during the time that this breaking change is in progress that all developers are fully blocked they cannot

make any business logic changes at all or even here testing on the test system when the database is not available then

QA engineer might be fully blocked in testing also automated tests which are hitting the database can't run oh and

also on the topic of database tests I do also want to mention that um our test fruit

he uh has slow execution time due to the database imagine if we had okay initially maybe

we had 10 tests later we have 50 tests uh 100 tests thousands of tests because of all of our business logic scenario

and each test is directly hitting the database it means that our test suit is now could

be taking several minutes to execute so this particular test suit is slow because we can see here that

it's indirectly depending on the database so the question is

is there a solution now before I go on uh let me see also the

the comments so how about a single point of failure so feel free to clarify but my

understanding is if this is relating to to the database the database is becoming a single point of failure and also a

single point of blockage for the whole team yes we may introduce some other type of

database like elasticsearch or redis for cache exactly we might be introducing replacing our let's say postgres

database by elasticsearch or redis or even you know switching to a completely

another type or even using you know two two databases essentially

so yeah basically the usage of of no no SQL so we've just had a discussion that yes we we

have this situation that we may need to switch to a database and this is causing such a huge pain

question is is there any solution to this kind of problem

so let's see the team was discussing it how can they solve it so they are thinking how can we

eliminate this uh dependency on the database can we maybe replace this real database by something else which is

like a real database but which is in memory in that case we don't care about which

technology is used by the real database so whether the real database is is active or not but we have this kind of

very reliable simulator it's essentially like a mock fake for our database so

let's introduce uh not uh we could introduce some kind of

mock database okay uh apologies I'm just going to draw it

above sorry I need I need to just make uh changes here so the issue is that this database access code this was the

part which for example had the actual orm code or whatever other mapping uh quote and we said we don't want business

logic to depend on the orm or SQL or what whatever else we have but instead we want to introduce something in

between so let's see what is the business logic going to depend upon

let's say we have some kind of a placeholder a placeholder for our persistence

some kind of persistence interface whereby we specified that we are interested to

um maybe add an order remove an order update an order from the persistence mechanism but we don't actually care

about the underlying technology so the business logic is now depending just on this interface

and then the choice that we're using a particular database and or SQL whatever would simply implement

that interface so maybe we have one kind of uh database which is let's say postgres so we have

let's say uh toys grass

persistence implementation [Applause] and maybe it's using

hibernate or whatever I mean I'll just put orm maybe we could be using mongodb

[Applause] and again it is implementing and let's see did we have anything else

uh or we could have elasticsearch or what what whatever else implemented so this this solves the possibility for

for multiple implementations to exist but we also mentioned that imagine in the case that there is

no database available or we want our test to run fast and there would be some kind of like

mock or fake persistence implementation and that one he does not have any

underlying storage it is purely in memory now I do want just to be more precise

here okay so we're focusing I mean only in business logic and what's below

about these arrows because this is where it can get a bit confusing so business logic we could say it is

using the persistence interface so this is like uh uses

but business logic uses or calls the presence persistence interface whereas these others like the more fake

persistence implementation or postgres implementation or mongodb implementation we could say they implement the

interface so we we're reading a bit in in reverse they implement the

interface and here I'd also want to say that somewhere with business business logic

we're implementing the order API whereas the word uses is uh the presentation is is using the rest API okay now since

we've done a lot of drawing up to now I want to go back to chat to see uh where we are okay I really like this

question because of the seen it so many times how many times in your experience do you switch database

from postgres to mySQL for your uh for the main agree to add nosql but it's another topic uh I I agree with this uh

I would say in terms of what is most common uh the part that is most common is

for example using an orm and then having to upgrade the orm is uh a common issue the other also common issue is the test

execution impact of the database so those are actually the biggest

problems and I would say they are the strongest motivators for why we want to switch to hexagonal architecture whereas

this one completely switching to a different database I know in practice it tends to be rarer but again I'm sure

there could be different answers to the to this question how how frequent is it business logic should persist via

interface contract so that we can use dependency injection to inject database file whatever I like that

file was also mentioned so that I can add it as well because maybe we're not even going to use a database at all

maybe we are going to have a file system that we are storing just um some data on files so that's another

possibility and I like the comment here about dependency injection that's exactly

correct so we can use a dependency injection [Applause]

dependency in injection Frameworks or any other mechanism

to inject the

persistence implementation whichever one and we can even configure maybe in our Startup configuration file

which which of the actual persistence mechanisms will be used that's exactly correct business logic code

does not depend on any of these implementation from a coding perspective but instead at runtime we can configure

which of these will actually be used so that's a great comment then a mock database or fake object

database could be used yes so the more coffee database object I would say their primary usage is for the

purposes of tests if we can just remember how we have tests up here the tests which are calling you know the

ordering API and ultimately when we're testing we would want to use you know the mock

or fake persistence implementations apologies orm here but that's exactly what would be used

but even at runtime we could be using um fakes

so one example of that is suppose you want to deliver a very fast customer demo and maybe you haven't even chosen

your database yet or don't want to spend the effort to build a whole database implementation but you could work

quickly with a fake or even if the database is down or let's say on the test system whatever so you could even

use fakes not just for automated tests but even to configure them to be used during actual execution

okay uh data syncing distributed State could be interesting okay so I see here the mention about

distributed systems that's yet another good topic uh at the moment uh for the purposes of this session we will be uh

staying only with the monolith application but in the future I think it would be nice to also explore hexagonal

architecture within distributed systems like with microservices how does it work together

okay nowadays testing with the real database infrastructure is easy enough with test containers okay so that has

become a point of um controversy and where there are

different opinions so back in the time when hexagonal architecture originated this possibility

did not exist at all the only possibility was either you have the real database or you

have some kind of mock fake and that's it there weren't any test containers so from that perspective that was I guess

the origin of a very very strong separation and similarly we can see even with Uncle Bob

who who essentially built up on hexagon architecture with clean architecture and again he is using all of the examples

are essentially replacing the database with an in-memory database then came along uh test containers

the challenge that Still Remains even with test containers is one challenge is still the runtime

again the difference between running the tests with test containers versus if we were running purely in memory so we have

the difference there and there's also another difference if we architecturally joined to

introduce this kind of Separation like business logic persistence interface and separating from implementation

it could occur the developers again start mixing business logic and uh database concerns which have issues for

modularity maintenance and and stuff like that but overall thanks for raising that topic I do know that there are

different opinions there so we also have the topic about inversion of control exactly so here

what we have done is basically inversion of uh control the business logic there's no it does not depend on any of these

implementations it depends only on the interface and it does not care or know about any

of this so since I mentioned that comment I do want to

uh add something here just to distinguish between I guess the grouping of

everything let me see we end up with

this kind of grouping I'm just going to bring this make this white and bring it to the

front thanks everyone for your patience okay

we essentially end up with this kind of thing but this is what what we are controlling

this is like the heart of our system and this is what Alistair cockburn calls the application

whereas this is just some technical names and these are the

let's start maybe from the top driver ports [Applause]

for user side ports and then I'll continue with the comments up after this

this is just okay introducing some terminology since we've reached um

this point in the drawing so we have the driver ports and we have the driven ports

this investor or it's called the server side ports and these things above like the rest API MVC tests all of everything

that's at this level we call them the driver adapters but they adapt to some technology

and also below we have the driven adapters I guess I'll write the word here

okay so I just wanted to point out that terminology as well oh and also a

reminder to myself the tests here I'll get to that in a minute but let's continue on with the

okay but a bit expensive if you use integrate unit or integration tests I'd prefer fake objects so the discussion

regarding which kind of test doubles to use I mean the more generic word here is uh

test doubles so I just want to add that as a note as well whether we're going to have a more fake

sub uh spy [Applause]

that's yet another discussion of its own I personally tend to use uh fakes because I find then that I get

reusability across tests and I get really high fidelity and also in the book software engineering at Google they

also tend to recommend using fakes as a test doubles uh do you have an example where the

ordering API interface would be implemented by other classes than BL classes if there is only one

implementation why use an interface I really like this question so in general

it is true that there would be only uh one implementation the question is

if there is only one implementation of the ordering API service why would we even

have this interface at all I will leave that as a thinking question for the audience I will note it and come

back to it later the question is why do we even need this interface if there's just one

implementation thank you but feel free to write any perspectives

in chat I will come back actually later to this question foreign

so even if you don't change the database or the test containers make testing easy you still would have the problem of

business logic leakage into the database layer I really um like that comment

because that that's the whole point the purpose here is not just test execution time but how are we modeling the system

and in the same way that we have problems when our UI logic becomes mixed with business logic and remember we

solve that by having some kind of interface so that presentation cannot just mix

freely with the business logic similarly the existence of this kind of interface forces Developers

to have this kind of separation if this interface did not exist and again if we could directly depend on

it then developers could write data X data access code anywhere so it's essentially indicating for separation of

concerns so yes this was a great comment and to add on shielding the business logic with uh interfaces tests are

regression tests also so that is right I mean here as when we go above to these tests these tests are hitting

essentially our application testing it through this API and we are sort of protecting the the

business logic from from any other concerns regardless of which side we're on

try test against the Mainframe okay um

question is is it okay okay to be I guess more more creative our system could integrate

with the Mainframe so if we needed to maybe get some data from the Mainframe or something we could

write an adapter like we could also have an adapter for over the Mainframe

so I like this not many people mention it we need an interface for it because we

want to test it um so I see multiple comments now about testing and interface and I will get

tests for for this interface as well so maybe I'll do that right now so

as we can see here uh how we have tests which are testing the

essentially the driver Port so they're testing the application in this way and here we will be replacing the

persistence interface with a mock surface but the question is

our tests are then spinning pretty much only this maybe I should even color coded I will

do a copy paste and color code because that we are aware of what

exactly our tests are spanning um okay maybe I'll use this as some kind of

color uh okay maybe a different one let me see okay I'll just green

so our tests are hitting uh here they are essentially testing

the whole application layer and they happen to be using these mocks and fakes in the implementation

as we can see here we have absolutely no tests targeting this if we look at all of this above so

what I need to emphasize here is that we have uh tests that we write tests

and we can see the symmetry okay these I mean different kind of tests so I'll choose a different color

in the same way that we have tests which are targeting the ordering API so targeting the driver ports similarly we

are going to have tests which are targeting the persistence interface

so let me choose a color there and it's a bit challenging to graphically represent it but when we

write these tests against the interface it means at runtime that we can apply these tests to any implementations that

we have so we write tests once for our persistence interface so we we write a test that when we

add let's say an order that we can retrieve back the order with the same data we're writing it against the

interface and then at runtime when we execute those tests for that adapter they would

be executed against all of these like against uh this this as well essentially

so that's the part about testing and since there's a lot of colors I will go

back to the uncolored version [Applause] and I'm going to just add the tests here

that we have a reminder that we have tests which are um essentially targeting the persistence

interface and then at run time they are executed against all of these um adapter implementations

is application the application layer uh this is a good question so often there's a lot of confusion

regarding the word application and this is why I didn't even use the word application at all until the very end of

this session so many people when you say the word application to them it might mean the

whole thing so it might mean the whole MVC application or the whole react application and

essentially involve everything so that's the way some people interpret it the way that uh that the definition of

application within um as the coke Burns hexagonal architecture is exclusively this

so application essentially encapsulates the business logic and it also has user side ports and server-side ports at the

boundary and that's it that's the the application so it's like a wrapper essentially

around business logic to protect the business logic from the external world some people may call this application

again due to all of this confusion about the word application I like to call it well this is not the official word but I

like to call it application core and I think I've seen that somewhere um

as well just with people are aware due to the multiple meanings of the word

application coded like you would maintain it uh so a big motivation behind hexagonal

architecture which does happen to be what we've reached uh right now is maintainability and testability

foreign of having the ordering API interface one can start development using it without

even having an implementation that is exactly correct it could mean that suppose we have a front-end team

you know they're making a react application okay and we're making a a rest API

and maybe some other external systems again need to interface with us whatever but we have not yet implemented the

business logic at all uh this could mean that essentially uh by having these interfaces

we do not even need this to have to be implemented but we can still immediately start working on our adapters

and even writing the adapter tests even the this implementation does not exist at

all so that is exactly uh one uh one motivation

for it and I would say it's quite an important motivation for it the other motivation is it prevents leakage of the

business logic so if the rest API MVC app if they can only have access to an interface now interface is quite

restrictive what what it exposes we could have this interface might consist just of you know free methods

create order cancel order our business logic might have hundreds of classes in it

the presentation layer by depending on the interface only would not have access to those 100 classes so the UI the

presentation concerns cannot be mixed it prevents the mixing with business logic so essentially enforcing higher

modularity so just to summarize by having this as an interface it means

that we can immediately start writing our adapter tests even in parallel and we just mock this out that's one

benefit and the other benefit is it really forces a strict boundary between the presentation and between the

business logic to prevent mixing of the business and the presentation logic and even though I use the word interface

here there are various ways of implementing it maybe we might get to it at the future points

okay shouldn't that be the the main layer uh instead so this business logic we could call it

the domain layer and that's the terminology that's used by Uncle Bob so Uncle Bob he calls the business logic he

calls this the entities or or domain layer and he calls this the use cases layer

and he calls this the Gateway interfaces so yes it's just different namings and if you

look at I mean the evolution well hexagon architecture is the foundation for all of them and just as we go on to

onion architecture and clean architecture some of the names inside could be different or more specific

having an interface for ordering API allow the parallel development business logic does not need to be ready in order

to start the rest API and vice versa as long as they only depend on the interface that's exactly correct so this

ordering API it is essentially representing the use cases of our system so I'll just write

because the word you know use cases yeah whereas these ones are like a gateways

[Applause] and when we're modeling the system we should be starting at our uh use cases

and this is exactly um allows us to work in such a way

can you share your diagram please okay I will have a look and I might comment later on YouTube

ordering API interfaces throw exceptions okay I might put that as a to-do for a subsequent session simply because we are

getting towards the end but I will put that to do uh throwing exceptions okay

let's move on the good thing about of having these interfaces is that you are describing

behaviors instead of uh Integrations that's correct these interfaces help us think about contracts

rather than the underlying technology thanks for that glad to hear that you enjoyed this presentation

this way it doesn't matter what changes might happen Beyond those interfaces because the behavior stays the same

until a new behavior is needed or or changed so we could say

that these are representing contracts and that those contracts are representing some kind of uh expected

Behavior behind the interface sorry sorry both of these are essentially contracts

and for the adapters they are concerned with specific

technology infrastructure concerns okay infrastructure concerns and I will okay same applies

here so it's completely different concerns and they change for different reasons

so that's yet another reason for this separation the application application core is

changing due to different due to changes required in use cases and business logic

whereas the adapters their reason for change is due to any technological changes or technological concerns which

is completely different concern compared to our business logic are the input adapters active or

reactive the request should invoke the interface starting Works business logic or would business logic be uh pooling or

maybe pulling the requests uh I'm not sure if I fully understood that one maybe feel free to clarify but I will

try my best to give a short response now but feel free to to clarify uh I will just explain what's happening as follows

so when we have a rest API controllers or the MVC controllers uh we can via dependency injection

inject the actual implementation of the ordering apis so I mean the actual code

it's dependent it's calling the ordering API so it's saying like ordering API you know dot uh create

order ordering API dot cancel orders so the actual controllers are literally calling the the API

in the source code then at runtime through dependency injection there's the dependency injection of the actual

implementation of the ordering API which is within the application and that one that's the actual execution so just to

summarize these controllers are directly calling the ordering API business logic

is uh directly calling the um persistence interface

so somewhere within business logic code we have a call towards you know our persistence interface which tends to be

called repository for example order Repository interface Dot add order order repository

interface dot uh update order dot delete order so it is

calling it uh directly calling it okay so yes the the there are Cliffhangers

since we do have some multiple open uh questions which I may use for for subsequent um uh live streaming sessions

since this is just the first one and this is like we're just getting started we need ordering API to instantiate the

whole application with different drivers and this is not the concern of the business logic that's

exactly correct indeed we have a completely another separate

thing it's called the composition route now this is not even it's not part of the hexual architecture diagram but

anyway it exists so the composition root is aware

of the application core and of all the adapters so that's actually the only thing that

is aware of everything that exists and then it is able to configure upfront time

um essentially uh all of these points uh one moment sorry

this is where there's dependency injection and and here as well okay is use cases also stand for driver ports

so I've put here the different terminology which tends to be used synonymously so

driver ports user side ports use cases so you can think of it essentially all of this here

okay thanks okay um I'm glad to hear that so since we did already go over the one hour uh I do

want to say um thanks to everyone again thanks for all your

comments uh okay did the yet another comment I'll add that to the to-do's so this was just the first of our live

streaming sessions about hexagon architecture and I really hope that that you enjoyed

this and that you found this useful as I mentioned this is just the first live streaming sessions uh I do plan on

having subsequent ones so for the next live streaming session uh I would like to see how all of this

transformation that we reached up to now how does this relate to Alistair conference article and that we can then

have a much better understanding of it and the other parts that I would also like to continue on in our next sessions

is further uh complexity let's say regarding the driven adapters so not

just databases but how do we deal with rabbit them Kafka with integrating with PayPal you know how do we do all of that

in a hexagonal architecture way and uh I'm also always open to any

comments questions because as you can see it is interactive so whatever you say all right uh will may affect what we

do um in the future and of course here I used an e-commerce example in the future

if you if you would like to see anything else you know feel free uh to let me know

so I would like to say once again thank you everyone for watching and I wish you all

the best and just to share again uh have a I encourage you all to look at these resources

and also feel free to connect with me or follow me on social media so uh thanks a lot everyone and I wish you a good day

thank you bye