Java Community | Help. Code. Learn.•5d ago

Hexagonal architecture question

Hi, I have a question on hexagonal architecture here. Does anyone know what it should be? https://stackoverflow.com/questions/79542731/hexagonal-architecture-question-with-respect-to-ports

Stack Overflow

Hexagonal architecture question with respect to ports

I have a question on naming conventions for ports and ports reusability. In hexagonal architecture, let's say I have this scenario where I make a call to an external api by another product. I have a

100 Replies

JavaBot•5d ago

⌛ This post has been reserved for your question.

Hey @Kale Vivi! Please use /close or the Close Post button above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically marked as dormant after 300 minutes of inactivity.

TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.

Peter Rader•5d ago

Yes. What's the question ❓ It's a approach to have two Adapters between two Microservices. One for each side. That's it in a nutshell

dan1st•5d ago

Are ports 1:1 with their implementations or many to 1 port?

You would typically have multiple implementations of a port

Kale ViviOP•5d ago

Sorry let me clarify Maybe the example I used is not great let's say we want to load data into a saas product. Let's call the saas productx. I want to make sure I'm making the gateway adapter as modular as possible so if we decided to change saas vendors later down the road, we can accomodate the change with this architecture pattern. Now, if i change from productx to producty, does the port also need to be a new port or should I really be reusing the same port?

dan1st•5d ago

the port is typically written in a way that's specific to your business logic so it has the operations your business logic needs but if another application/product needs the same operations, you could in principle reuse it though the hexagonal architecture doesn't really promote that reuse AFAIK at that point, you might even want to consider the "a little copying is better than a new dependency" principle also you don't necessarily need to include the product name in the port name since the port is part of the codebase of that product (at least if it isn't referenced outside of the product code)

Kale ViviOP•5d ago

That's where I'm confused. I thought it did but why do you say that? It wouldn't be. Saas will be an external product managed by the vendor. We are just managing a service that contains the code to load data in there. I might just make it more agnostic then but yeah

dan1st•5d ago

ports are specific to the application/business logic everything in the hexagonal architecture is kinda about the business logic in some way lol so the ports should have the operations needed by your application

Kale ViviOP•5d ago

lol how does it work then if I'm interfacing with extenal systems?

dan1st•5d ago

well you have a port and an implementation

Kale ViviOP•5d ago

yeah I agree sorry I think I got confused by " ports should have the operations needed by your application"

dan1st•5d ago

so you create the port - and then you create the implementation that interacts with the external system

Kale ViviOP•5d ago

I mean yes I want to do add a method signature for loading data loadFoo(List<Foo> foo) in my port my application calls that method to load data into the other system right that's my gateway

dan1st•5d ago

You aren't implementing operations you don't need in your application. And you aren't making your ports more general. The ports do exactly what the application needs from the gateway or whatever external system you are using

Kale ViviOP•5d ago

I mean to say sorry if I wasn't clear if all I'm doing later down the road is switching from productx to producty and I have the same requirements, why not reuse the same port? or is that discouraged? thats' mainly what I'm trying to understand

dan1st•5d ago

you can but you might have slightly different requirements and then you need a different port In the hexagonal architecture, you shouldn't need to change your business logic because of externals systems changing or other products

Kale ViviOP•5d ago

but this includes the port right? XD

dan1st•5d ago

yes if the port changes, you need to adapt your business logic to that change, right?

Kale ViviOP•5d ago

then I should be reusing it?

dan1st•5d ago

With reuse, do you mean copying the (parts of) the code or do you mean extracting the port into another component and using that component in both products?

Kale ViviOP•5d ago

for example if I switch from productx to producty.. I create a new gateway productygateway and I have that implement the same port as the productx previously. I don't need to make any changes there

dan1st•5d ago

. What do you mean with implementing the same port?

Kale ViviOP•5d ago

Let's say like this

dan1st•5d ago

copying the interface or creating a dependency and using that dependency in both components?

Kale ViviOP•5d ago

Let's say I have my app, App A: I have this class ProductXGateway which has ProductXGateway implements ProductXGatewayPort I have a new product to integrate with and I have a new gateway (new logic) and it looks like ProductYGateway implements ProductXGatewayPort Bad port name aside, within the port it says a method string loadFoo(List<Foo> foo) Which just takes foo objects from our application and loads into the respective product I'm interfacing with. The port doesn't know anything about the product, just that it needs to load those objects. The implementation details are part of the gateway itself. So can't I just reuse this port (albeit I should probably name it better to not be associated with a product)? the latter but it's really swapping out the gateway/impl inplace of having both

dan1st•5d ago

ok so let's assume both products have the exact same things you want to expose. Then you might have a new requirement in the future for one product but not the other. What are you doing now?

Kale ViviOP•5d ago

that's what I'm saying lol can I reuse the port? I just want to swap up the implementation but I can just implement the same port lol

dan1st•5d ago

strictly speaking (when strictly following the hexagonal architecture), no

Kale ViviOP•5d ago

interesting, why not? That's what I'm asking to understand better

dan1st•5d ago

because of that

Kale ViviOP•5d ago

can you elaborate why it would be an issue?

dan1st•5d ago

Can you answer the question I asked in that message? https://discord.com/channels/648956210850299986/1355564500325236746/1355581533511090267

Shruti•5d ago

ok so let's assume both products have the exact same things you want to expose. Then you might have a new requirement in the future for one product but not the other. What are you doing now?

Kale ViviOP•5d ago

I already answered it thats' why I'm confused Answered it here

dan1st•5d ago

you meant that?

Kale ViviOP•5d ago

yes exactly that why not? and what would be the issue

dan1st•5d ago

The port does often know about the product But let me clarify what I meant with having a new requirements so the port is an interface implemented somewhere in your application, right?

Kale ViviOP•5d ago

yup just an interface

dan1st•5d ago

Now let's say you are using the same port for product X and Y That means if you change the port, you need to change it for both product X and Y

Kale ViviOP•5d ago

right but why would I change the port?

dan1st•5d ago

ok let's say there's a new functionality in product X and that functionality needs to be accessible from outside via the gateway or whatever

Kale ViviOP•5d ago

and also I think I might see your confusion here, I would only swap the impl for my case not have both products implement the port at the same time

dan1st•5d ago

then you might need a new method in the port

Kale ViviOP•5d ago

so no issues if port contract changes in place becuse it would only impact the new product implementing it

dan1st•5d ago

What? So if the requirements of product X changes, you might need changes to the port

Kale ViviOP•5d ago

Like I'm moving from Product X to Product Y LOL not having both

dan1st•5d ago

ohhhhh So you are saying you replace product X with product Y

Kale ViviOP•5d ago

yeah

dan1st•5d ago

ah ok

Kale ViviOP•5d ago

(but you could be right though in the sense that migration might be slow and not ideal to reuse the port? - not a hard quick but could be a slow one)

dan1st•5d ago

in principle, yes - but in this case, I would just copy the code for the port because a rewrite might take time and during that rewrite, there may be changes you'd make to the new product

Kale ViviOP•5d ago

yeah good point, ok I'll keep the ports separate as is then

dan1st•5d ago

also adding a new dependency just for that would be work

Kale ViviOP•5d ago

but yeah I can copy the same method signatures if similar/same

dan1st•5d ago

since the old project isn't gonna be used much anyway, you can just copy it and that also gives you the freedom to make changes to the port but if you mostly want a compatible replacement, copying the port makes sense - since you might be able to reuse the tests and other things also ofc all of this is assuming that both product X and product Y are using the hexagonal architecture

Kale ViviOP•5d ago

Sooo sorry for the ambigious names but like I'm coding this in ApplicationA for example

dan1st•5d ago

it isn't about the names

Kale ViviOP•5d ago

and the products are external

dan1st•5d ago

and you don't need to be sorry

Kale ViviOP•5d ago

we just interface with them this code lies outside of those products if that makes sense in app a

dan1st•5d ago

Is app A using product X/Y or is product X/Y using app A?

Kale ViviOP•5d ago

app is a middlware to get data in and out of product X/y I guess product x/y uses app a? not sure how to explain it or other way around

dan1st•5d ago

so the app is sending request to product X/Y asking these products for things

Kale ViviOP•5d ago

no the other way

dan1st•5d ago

yep

Kale ViviOP•5d ago

right now it's just loading data app -> product x

dan1st•5d ago

And is it App A or product X/Y that's using the hexagonal architecture in your current question?

Kale ViviOP•5d ago

app A we are building out the middlware

dan1st•5d ago

Kale ViviOP•5d ago

product x is saas that we don't control

dan1st•5d ago

~~Then I'm asking you: Are we talking about ports or are we talking about adapters for that case?~~

Kale ViviOP•5d ago

the gateway (adapter) has the implementation logic here the gateway makes a rest api call to load data into product x

dan1st•5d ago

So we are talking about the driven side

Kale ViviOP•5d ago

it gets data from our db that actually was my second question is the gateway a driver or driven here?

dan1st•5d ago

you have interfaces (the port) and your application is calling these interfaces the application/business logic is not implementing the interfaces, it is calling the interfaces because it's the driven side right?

Kale ViviOP•5d ago

a scheduler in app a is triggering the data load into product x the scheduler calls a controller endpoint which calls a service which calls a gateway to load the data to the rest api for product x lol

dan1st•5d ago

and the app is the gateway?

Kale ViviOP•5d ago

the app contains this gateway see the code-review question for gateway implementation LOL

dan1st•5d ago

I haven't looked at that because I don't really feel like doing code review rn lol

Kale ViviOP•5d ago

no worries but that would explain what happens in the gateway right now the app contains all the HA code

dan1st•5d ago

What is your exact question now?

Kale ViviOP•5d ago

controllers, services, gateway

dan1st•5d ago

high availability, right? just to be sure

Kale ViviOP•5d ago

hexagonal architecture lol

dan1st•5d ago

lol

Kale ViviOP•5d ago

My other question was this is driver or driven adapter LOL the gateway here the scheduler calls a controller endpoint which calls a service which calls a gateway to load the data to the rest api for product x lol

dan1st•5d ago

Your application calls something else your application is actually the component acting it's requesting data so the adapter is on the driven side and it would look like that

public interface ProductPort {//other names are possible - for example you might not need the 'Port' suffix
  YourResultType someFunctionalityOfProduct(Arguments here);
  //possibly other methods
}

public interface ProductPort {//other names are possible - for example you might not need the 'Port' suffix
  YourResultType someFunctionalityOfProduct(Arguments here);
  //possibly other methods
}

and in your application

private final ProductPort product;//you can inject this via DI or whatever

void doSomething(){
  YourResultType result = someFunctionalityOfProduct(...);
}

private final ProductPort product;//you can inject this via DI or whatever

void doSomething(){
  YourResultType result = someFunctionalityOfProduct(...);
}

and here, ProductPort is specific to the application but written in a way that it does what the application needs It is not specific to product X or Y you can switch out product X with product Y without changing the port - you just write another adapter The things I mentioned before about changing requirements to products and the port having to change: That's about the other side/the exact opposite scenario (when we're talking about product X/Y using the hexagonal architecture and when talking about these)

Kale ViviOP•5d ago

First of all, thank you for the explanation above. Makes sense. Second of all, lol, now then I feel like I'm back to square one... is it better to have that application reusable port or two different ports because application requirements interfacing with those products could have new requirements?

JavaBot•5d ago

If you are finished with your post, please close it. If you are not, please ignore this message. Note that you will not be able to send further messages here after this post have been closed but you will be able to create new posts.

Kale ViviOP•5d ago

Or rather mainly what does hexagonal architecture say to enforce?

dan1st•5d ago

At the beginning, we were talking (at least that's what I thought you were asking about and talked about) about using the same port for two different hexagonal architecture applications where I told you why that would be a bad idea. Now, when we were talking about app interacting with external product X/Y, you would use the same port for both The port is part of the application - it's specific to your business logic but not specific to the external product X/Y

Kale ViviOP•5d ago

Yeah exactly I think it makes sense to use the same port too but honestly, you did bring up a goood point on what if I need to maintain both gateways for a brief period. I'm wondering if I would ever encounter a scenario where let's say product Y has a new feature that I need to implement and I want to add the definition in my port for new feature but product X doesn't support it. That would be an issue I guess maybe but maybe I can worry about later

dan1st•5d ago

.Even when maintaining two adapters: You'd have the same port the port specifies what your application needs from the products the port is independent from the actual product

Kale ViviOP•5d ago

ok I'll make the changes then. I accidentally named my port ProductXGatewayPort but I see that is not a good name now Thanks for confirming my understand and how to use ports correctly for modularization here

JavaBot•5d ago

Kale ViviOP•5d ago

I appreciate your time here Thanks

dan1st•5d ago

btw if it's obvious that the class is a port, you might also omit the "Port" suffix from the name - but please be consistent (do the same with all ports)

Kale ViviOP•5d ago

I thought it might help with saying hey this in interface when doing lookups and things

dan1st•5d ago

You should do what's clearer/more readable/more maintainable

Kale ViviOP•5d ago

ok thanks

JavaBot•5d ago

Post Closed

This post has been closed by <@227594989012516865>.

Gaming

Programming

Hexagonal architecture question

Did you find this page helpful?