Hexagonal Architecture (All You Need to Know)
Vložit
- čas přidán 12. 02. 2024
- Watch as I show you what you should know about Hexagonal Architecture.
💎 Be a Patreon: / gsferreira
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
💌 Free Developer Insights: guiferreira.me/newsletter
📞 Book a 1:1 Call with me: calendly.com/gsferreira/coach...
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsferreira
Get my newsletters: guiferreira.me/newsletter
Visit my blog: gsferreira.com
👋 WHO AM I
Hey! If you're new to my Channel, I'm Guilherme. Call me Gui. I'm a Minimalist Software Craftsman. What do I do here? I share tips on how to simplify your life as a Developer.
🎵 MUSIC CREDITS
White Lie / StreamBeats / Lofi
#softwaredevelopment #softwarearchitecture
Thanks for the video! The dependency issue coming from a n-layered architecture can be simply resolved by putting all interfaces on a separate project and enforce the use of interfaces. I have worked with both clean and hex architectures in both java and c# and my personal experience is that they are a nightmare to work with as they are not intuitive at all and it's very difficult to onboard people. Use them carefully and try them for some time before productionising!
I believe that the nightmare starts when we don't keep it simple. That's why I like Hexagonal. It's easy to explain and to keep it in a simple way.
Great summary of the concepts of this architecture 👍How do you decide which third-party library you let into your hexagon? Or do you put "everything" behind a port? What about FluentValidations for example or the famous MediatR?
Excellent question. If the library serves the connection of my hexagon to the external world, it goes into an Adapter.
Example: npgsql will be in an adapter, while MediatR will be part of my hexagon.
Do you follow another approach?
@@gui.ferreira I try to be very strict and let as few libraries into my application logic directly as possible 😉
Hey don't bash on people who build their own ORM 😆 I still use the one I created back in 2007 (but ofc modernized it and keep it updated) and it works way way better than any ORM offered today in a fancy package. 😆
More than 15 years of utilization, already justifies the investment 😅
@@gui.ferreira tru tru 😀
I use a micro services architecture for my game dev, and this doesn’t really work for game dev, but I’ll keep it in the back of my mind!
I agree. In most microservices (when they are in fact micro) it usually isn't needed.
Hi thanks for your videos. Can you maybe make one for Kafka Streams with dotnet?
Hi! Thanks 🙏
I'm not sure If I'm the best person to talk about Streams. But I will add it to my list and think about it.
Thanks for the suggestion.
Is this aplicable to microservices? Is it needed then? Seems like over engineering for me. But also dont like thinking that this will be useful when working with monoliths only.
It's a tradeoff.
You will get testability and device independence. But, if it's a tiny service, such as a Service with a single responsibility to ingest a queue into a database, you might not get much out of it.
Even then, designing applications as a 3-part system (input, core, output) is not such a big overhead and can be useful. By the way, each part doesn't need to be a different project or package.
This is a wonderful channel. I watched all your videos about hexagonal architecture. But I still have questions in my mind. I really can't see a difference between n-tier architecture and hexagonal when you applied dependency injection for every technology you used. For example, in data access layer, I can have an interface called IProductRepository which includes necessary methods. Then I can have a concrete class which name is like EFProductRepository implementing IProductRepository. If one day I would like to switch my ORM technology, then I can create another concrete class like DapperProductRepository implementing IProductRepository again. And it is still testable independent from technology. By using dependency injection, they are loose-coupled as well.
What if I told you that what you described is not n-tier architecture anymore? 😉 It's how we naturally fight the problems of multitier architecture.
I know that Wikipedia is not perfect, but if we look into the multitier architecture it says:
"A layer is on top of another, because it depends on it. Every layer can exist without the layers above it, and requires the layers below it to function."
en.wikipedia.org/wiki/Multitier_architecture
According to your description, your "business" layer no longer depends on the data access layer.
Am I correct?
@@gui.ferreira You are right. My "business" layer doesn't depend on Data Access Layer. So, what is the name of this architecture then if it is not multi-tier or hexagonal?
@@BarbarosYurttagul From your description, you have a domain-centric architecture. On that family of architectures, you can find Hexagonal, Clean Arch or Onion.
I would need to look into the complete blueprint to name it. However, the name is not the most important thing.
If you apply the principles of Hexagonal, I bet you are in a good place.