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!

@gui.ferreira

4 ай бұрын

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?

@gui.ferreira

4 ай бұрын

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?

@AboutCleanCode

4 ай бұрын

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

@gui.ferreira

Ай бұрын

More than 15 years of utilization, already justifies the investment 😅

@eramires

Ай бұрын

@@gui.ferreira tru tru 😀

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

@gui.ferreira

4 ай бұрын

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.

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!

@gui.ferreira

4 ай бұрын

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.

@gui.ferreira

4 ай бұрын

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?

@BarbarosYurttagul

4 ай бұрын

@@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?

@gui.ferreira

4 ай бұрын

​@@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.

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.

@gui.ferreira

Ай бұрын

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.