I looked into the lemmy src, and what is supposed to be a CRUD API has several layers of abstraction. Same at work, where we have hexagonally structured apps where following any sort of logic is literally impossible. What are your thoughts?
mind if i ask what ‘hexagonally structured’ means? i have never heard of this and cant imagine what it could be :D
The hexagonal architecture or onion architecture is oversimplified as having everything bolt onto a core of business logic via designed and designated interfaces to abstract away implementation details on either side.
Say you have a web app which takes requests from the outside world and based on those requests it performs some business logic (tracking accounts, orders, etc).
In hexagonal architecture you’d maybe implement such a thing like:
Web app handler -> command interface -> message bus -> command handler (business logic) -> repository interface -> repository (Postgres, mongo, memory, email)
What this lets you do is split apart the app at the interfaces into separate modules which can be reasoned about and tested separately.
End of the day you don’t care what is happening on the other side of the interface as long as whatever it is follows the interface specification.
Building applications like this meants that if we wanted to extend our app with an API and a Real-time Websocket service, we can (usually) just write a handler to turn that request into a command for the command interface and be done with it.
cool, thanks for the explanation :) i am familiar with onion architecture, i just never heard of hexagonal arch. i assumed there would be some difference
adapter-core domain logic- port
basically you make an onion, where the core domain logic handles well, your actual logic the adapter handles requests and makes them understandable for your core part the port part is your db or anything like that, it’s usually an implementation of an interface
Yes it does. It only makes testing things that should not exist otherwise easier.
The thing about larger-scale architecture is that you can be correct in any specific sense that it’s more than you need, but when you actually try to make the thing across a development team, you end up there because the code reflects the organization, and having it broken up like that lets you more easily rewrite your previous decisions.
At the small scale this occurs when you notice that the way in which you have to approach a feature is linguistically different - it needs conversion to a substantially different data structure, or an interface that compiles imperative commands from a definition. The whole idea of the database having a general purpose structure and its own query language emerges from that - it lets you defer the question of exactly how you want to use the data. The more configuration you add, the more of those layers you need. When you start supporting enterprise-grade flexibility it gets out of control and you end up with a configuration language that resembles a general purpose programming environment, but worse.
Casey Muratori talks about this kind of thing in some depth.
In the end, the point of the code is to help you “arrive in the future” in some sense - it’s instrumental, the point of automating it is to improve the quality of your result by some metric(e.g. fewer errors). For a lot of computations, that means you should just use a spreadsheet - it aids the data entry task, it automates enough of the detail that you can get things done, but it also gets out of the way instead of turning into a professionalized project.
I’ve coded most of my applications in that structure. It makes changing and testing things sane. Plus, if I need to make a large backend change, I can keep the abstractions compatible and have the rest of the app not notice.
I don’t know every time I’ve tried to change a beast like that, it was hard and frustrating.
There are a few possible reasons for that, but the main ones are:
The architecture may be from the rococo (filled with pretty, but ultimately useless and confusing “decorations”) or surrealist (tenuous relationship to reality) schools. This would make it difficult to grasp for anyone but the people involved from the beginning.
The architecture could be perfectly sound, but for some reason, you are having trouble putting it all together. The most common reason for that is a lack of training and documentation.
If you know how hex arch works and the dir structure is documented it should not be hard to follow a code path all the way through the stack quickly.
