Ports and Adapters Architecture | Hacker News Reader

Ports and Adapters Architecture

herbertograca.com

29 pointshgraca16 comments

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.

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.

You can go overboard though. Excessively loose coupling can come at the expense of DRY (and vice versa). It's a trade off.

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.

I also found this text to be very concise and useful description of P&A http://www.dossier-andreas.net/software_architecture/ports_a...

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.

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.

You should be old enough to remember arsDigita was tightly coupled to Oracle, and the move to pgsql (iirc) in openars took forever.

The main issues I faced in this respect are EOLing (specifically, by license change, or incompatible technical change - e.g. A 16 bit lib unavailable for 32 bit or a 32 bit lib unavailable for 64)

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?

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.

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.

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.

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.

Thanks for that explanation, I think I get that. The part that still worries me though, is how absolutely everything in the app is decoupled, even where tighter coupling makes sense, like where the coupling doesn't pass through a security boundary. Also not sure how the terms facade and interface are overloaded?

sounds like https://en.wikipedia.org/wiki/Signals_and_slots

They must really hate classes and OOP.

Reply on news.ycombinator.com