After starting the design of a sample application with Hexagonal Architecture I got to the application layer that should be basically an API to manipulate the domain in some way. My question is: In what form should I pass the parameters to the application layer? I can't pass anything contained in the domain because it would make the Adapter dependent directly on the domain. I thought about using DTOs(http://bit.ly/2cPal0D) to pass information from the adapter to the application layer, but I'm not sure this is the best idea.

Any suggestions based on passed experiences.

  • Why can't adapter depend directly on the domain? – Euphoric Sep 11 '16 at 4:20
  • In your version of Hexagonal Architecture what is at the core: application or domain? – candied_orange Sep 11 '16 at 5:35
  • When I wrote the question I was thing of application as a thin layer that operates over the domain through well application services. And as domain I wanted to mean the domain model, that contain only classes related to the domain in some way. @CandiedOrange – Lucas Piske Sep 12 '16 at 1:48

Sounds like you want to do this

  / Application  \
 /    .------.    \
.    < Domain >    .
 \    '------'    / 
  \              /

And you're not sure how the adapter fits in. This is the adapter pattern:

enter image description here

That works fine when the flow of control is just going from the outside in. How does it ever get back out?

Here's an extremely similar architecture that shows how to solve that problem:

enter image description here

The names and shapes are different and really not that important. The cool thing here is down in that lower right corner. Uncle bob calls that a plugin (because everyone has to have different names for these things). It shows how to get in and out of lower layers without dependencies going the wrong direction. The <I> thing marks the interfaces.

This all comes down to respecting the dependency inversion principle. Following that can look like this:

enter image description here

Notice how that looks a lot like the adapter? The difference is just one more interface. It also looks a lot like that plugin if you just rotate the last 2 boxes 90 degrees and then flip the whole thing.

To me, this whole "architecture" thing is about managing what is allowed to know about what while still getting things done.

You were concerned about passing things contained in the domain. I hope this shows you that where something is contained isn't the issue. The issue is where the interface lives. You'll notice presenter's interface isn't even in the same layer. You should rely on interfaces only so long as they are defined no further from the core than you are. That way you can always peel off and swap out outer layers. The inner layers won't know a thing has changed. They don't know about the outer layers. They don't want to know.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.