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’ve used this long before it was ever given a name, and while most know it as Hex Arch, I call it XPlicit Arch, since architect is supposed to be about interfaces and contracts, not implementations. For you C guys out there, when he speaks of Ports, think Interface or abstract class, and adapters can be 2 things (either an interface implementing class or abstract class that implements that interface but serves as a translator). There is some cost to this architecture, as it’s not easy for junior or mid level coders to fathom at first, but it pays off for enterprise solutions. It’s Dependency Injection intensive, so it makes people code to interfaces, another plus. Also, it doesn’t have to be followed exactly, and you can use it as your enterprise core architecture, which it is ideal for, but it can also be applied in an complex application as well. For instance, a web portal might have it’s own entire hexagon that interacts with the “Core” enterprise hexagon. The main thing to realize is that nothing deals with concrete instances except the deepest regions in the Core of each hexagon. Everything is talking to each other via interfaces, allowing for future change and flexibility. Search “The Software Architecture Chronicles” by Herbert Graca for a thorough explanation on this architecture.

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. 😆

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?

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!

Hi thanks for your videos. Can you maybe make one for Kafka Streams with dotnet?

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.

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.