
Ports and Adapters Architecture - hgraca
https://herbertograca.com/2017/09/14/ports-adapters-architecture/
======
xwvvvvwx
So the benefits to testing seem clear and compelling. But I cringed a little
when I read the bit about wanting to maybe one day swap out the search
backend.

A pretty big chunk of the code that annoys me most at work is a result of this
kind of premature abstraction ("maybe we'll need to swap out the database
layer one day"). As far as I can tell most of the time this is never needed,
and the net time lost by hundreds of developers over several years is much
greater than the cost of forgoing the extra layers and just making the
transition the hard way as and when it's required.

~~~
UK-AL
But when you do need it, and you haven't put in the mechanisms to replace it.
Your screwed.

Without the proper abstractions things can become tightly coupled, and your
going to spend a lot of time untangling it.

I've been on projects like this, and spent a lot of time getting annoyed at
the lack of foresight.

~~~
lgas
The problem is that few projects survive long enough to get to the point where
anyone can be annoyed by the lack of foresight... so often any foresight or
effort on implementing what was foreseen is wasted effort. Often times that
wasted effort contributes to the premature death of the project by soaking up
resources that could've been used to implement more features, fix more bugs,
etc. The question is which is more problematic, the lack of foreseeing the
need to change the database or the lack of foreseeing the death of the project
due to spending time on the wrong things? Personally I think having a
successful project that needs the database changed is a) not a particularly
hard problem to deal with and b) a good problem to have.

------
ivanche
I also found this text to be very concise and useful description of P&A
[http://www.dossier-
andreas.net/software_architecture/ports_a...](http://www.dossier-
andreas.net/software_architecture/ports_and_adapters.html)

------
TeeWEE
The big win is easy swappable port implementations. Which makes unit testing
super fast. It's a better separation of concerns. The ports or often
implemented as interfaces.

~~~
Spearchucker
I question the utility. In my 27 years in this business I've never come across
a database migration, for example. And the only reason you'd put all that
effort into a port for data access is to hedge against a future switch to
another database vendor/technology. It feels like ports and adapters are
intended to indulge a desire for "the best" architecture, where "a successful"
architecture would do.

~~~
icebraining
_I question the utility. In my 27 years in this business I 've never come
across a database migration, for example._

How much would you have come across if most applications implemented this
pattern, though? There's some selection bias at play.

Or to look at it from the other side: how many times have you come across a
switch when this pattern was implicitly implemented in the application by
virtue of using a standard protocol, like SMTP?

------
Spearchucker
Never understood the value of ports and adaptors. If you want isolation in a
layered design, use a service façade and a service interface.

Layers are a lot easier to comprehend than hexagons. That makes other tasks
easier, like planning deployment of layers into tiers, through which routes
are similarly linear.

~~~
macca321
A port IS just a service facade/interface. An adaptor IS just a specific
implementation of a service.

Think of P&A as terminology to help you disambiguate these use cases from the
extremely overloaded words. If your team know these terms, it makes a lot of
discussions a lot clearer.

The hexagon thing is a bit of a red herring IMO. I think of it as dependency
inversion at the module level, rather than the class level.

~~~
derriz
In what way is the term "service facade/interface" overloaded? I've never
encountered confusion (or been confused) by its usage in the context of
discussing software development.

On the other hand, "port" is already completely overloaded: serial interface,
TCP socket endpoint, etc. Further overloading it - particularly when there is
a widely used term for the same thing - makes no sense.

Reinventing terms for existing concepts does nothing - in my mind - to advance
the state of art.

~~~
macca321
OK, an example: a LOT of .NET/Java codebases have these (IMO smelly)
constructs:

class FooService : IFooService{} interface IFooService {}

where there is an interface with a single implementation. In this case, the
"service interface" isn't a port, because it's not actually decoupled from the
domain.

It has the potential to be one, but only if the FooService is extracted,
dereferenced from the domain, and the application composes the FooService.

Saying "we need to make this into a port and adapter" gets the point across
very quickly.

------
jlebrech
sounds like
[https://en.wikipedia.org/wiki/Signals_and_slots](https://en.wikipedia.org/wiki/Signals_and_slots)

------
transverse
They must really hate classes and OOP.

