1

I've been trying to refactor a brand new project to follow the hexagonal architecture and ddd patterns.

Domain structure

This is the structure of my domain. I have files and customer data. Entity wise this makes sense to be separated. The "facade" objects connect the ports with the domain. Quick example:

Controller (application layer) --uses--> Facade --uses--> Ports <--implement-- Adapters (infrastructure layer)

The problem I have is I have a third adapter (not in the picture) that is an external OCR app. It's an external client (we use a feign client to connect their API) and it provides customer data (first adapter), but also serves us with the raw data of images (second adapter).

My first two adapters have entities, repos and databases on our local systems but, this third one, to me makes sense given the theory behind hexagonal architecture, to be separated in its own adapter.

But then how do I use it from my other two adapters? Should the three of them be in the same adapter since they depend on each other? CustomerData and File have a One To Many relationship as well so maybe it makes sense?

I have only implemented the File part so far and have yet to refactor the CustomerData part since I'm trying to wrap my head around the concepts first.

I've seen a lot of articles but most of them are really simple with no real world examples and they have clearly separated domains.

Thanks a lot for the clarification in advance.

Jose Climent
  • 57
  • 1
  • 10
  • This recent answer might give you some background: https://stackoverflow.com/a/72537033/615119. – Farhan Nasim Jun 08 '22 at 11:38
  • It is interesting @FarhanNasim. In that file structure it seems like there is all wrapped up into one adapter though, since there are several services at the same level and repos as well. In your example, could the concrete services of the port package depend on each other? I feel like if I could use one "Facade" from another one in my example everything would be solved, but at the same time I feel like it violates the design pattern. – Jose Climent Jun 08 '22 at 12:18
  • Another thing I could maybe do is to have an adapter with a feign client to the external service, each one with different endpoints instead of a feign client to the external service that has all the endpoints configured. The problem is that would imply duplicating config etc. – Jose Climent Jun 08 '22 at 12:20

2 Answers2

0

In lack of a better idea, since the interface ports are beans implemented by the facades, I'm wiring the ports I need in the other domain's facades and using them the same way as if it was a controller of that same domain. The diagram would be something similar to:

Facade (domain1) --uses--> Port (of domain2) <--implement-- Adapters (infrastructure layer)

Edit:

I've found out a very extensive article that is very useful to understand hexagonal architecture but goes even deeper.

Long story short, I'll copy the relevant part:

Triggering logic in other components

When one of our components (component B) needs to do something whenever something else happens in another component (component A), we can not simply make a direct call from component A to a class/method in component B because A would then be coupled to B.

However we can make A use an event dispatcher to dispatch an application event that will be delivered to any component listening to it, including B, and the event listener in B will trigger the desired action. This means that component A will depend on an event dispatcher, but it will be decoupled from B.

Jose Climent
  • 57
  • 1
  • 10
0

Hexagonal Architecture doesn't forbid the relationships between adapters.

Anyway, usually we will have a port for each external actor interacting with our business logic, and an adapter to translate to/from the actor.

You can take a look at this:

https://jmgarridopaz.github.io/content/hexagonalarchitecture-ig/chapter1.html

choquero70
  • 4,470
  • 2
  • 28
  • 48