4 ms·
I don't know what an onion is in programming terms. But each of those problems can be solved without one? --- 1. "Adding a field to our API" Parsing: You tu
by dgb23 2y ago
I don't know what an onion is in programming terms.
But each of those problems can be solved without one?
---
1. "Adding a field to our API"
Parsing: You turn external input into an internal representation.
2. "Introducing a new downstream dependency"
Essentially the same as above, but presumably bi-directional: You also turn your internal representation into something that is understood by your dependency.
3. "Introducing a new library dependency"
I don't quite understand this example. Apparently writing a module that uses a third party library is an onion layer?
---
Can someone explain what I'm missing?
- whalesalad 2y agoSeparation of concerns, essentially. https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...
- projektfu 2y agoThis particular article seems to advocate "adapt all the things!!!" using dependency injection to configure your adapters. I'd not come across onion architecture before but I'm a big fan of hexagonal architecture. The essential difference is that onion architecture wants dependency injection, adapters and a pure core, where pure just means no dependencies of any kind. Hexagonal architecture has the concept of internal and external, and advocates treating everything that is not part of the application as a consumer. In hexagonal architecture, a database may be an internal implementation detail, or it may be something external things expect to use and have a defined schema, etc. In the first case, it doesn't need special abstraction, in the second, it needs to be treated as something to adapt to. Onion architecture would say that it is a dependency and should be externalized from the start.