This is exactly the reason why I feel the more trivial an application becomes the more difficult it’s to starting using an hexagonal architecture for it as one will constantly be thinking about all the added complexity without much tangible benefits. If all an app does is forward inputs to storage there’s no “core functionality” to speak of.
That’s why I suggested a calculator as a better example. It does actually have core functionality. This core functionality might be powered by a CLI interface, but could just as well be adapted to e.g. an http interface.
Tbh most phoenix projects use an architecture, where the http interface is already optional, as functionality is contained in contexts not in controllers. So there are lot’s of examples on that end. A good one might be nerves_hub, as it actually has both a CLI and a web based interface. There are few projects I know however, which treat their database as the bad outside world, which you’d need an interface/adapter for.
There’s a cost/benefit decision to take for keeping functionality hidden behind an interface and as most people seem to be controlling their db in their stack the benefits are not as great as e.g. for a third party api, where uncontrolled network and services are involved. For third party apis you often see them hidden behind interfaces even just to enable mocking. I found the unit testing book of manning to actually explore the space of internal vs external dependencies quite well. Most people only put dependencies behind interfaces, which they’ll also mock (Unmanaged dependencies* in the books terms), but don’t do that for things they don’t mock (Managed dependencies** in the books terms).
- out-of-process dependencies you don’t have full control over
** out-of-process dependencies you have full control over
