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?
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:
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
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@beehaw.org
All things programming and coding related. Subcommunity of Technology.
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
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.