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?
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!
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. 😆
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.
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.
Thanks for sharing. I agree with you that it can be harder for a Junior, but I think it's easier to get it than other styles. Those articles by Herberto are amazing.
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 😉
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.
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.
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 😀
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.
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.
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.
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.
Thanks for sharing. I agree with you that it can be harder for a Junior, but I think it's easier to get it than other styles.
Those articles by Herberto are amazing.