Onion Architecture vs Clean Architecture Comparison

Подписаться 89 тыс.

Просмотров 37 тыс.

50% 1

Get the source code for this video for FREE → the-dotnet-weekly.ck.page/cle...
☄️ Master the Modular Monolith Architecture: bit.ly/3SXlzSt
📌 Accelerate your Clean Architecture skills: bit.ly/3PupkOJ
🚀 Support me on Patreon to access the source code: / milanjovanovic
Onion architecture and Clean architecture are often confused. And there's a good reason for that. It's because they are practically identical. Clean architecture is just a repackaging of Onion architecture and Hexagonal architecture principles. I'll compare them in this video, and you be the judge of how different they actually are.
Onion architecture series, Jeffrey Palermo:
- jeffreypalermo.com/2008/07/th...
- jeffreypalermo.com/2008/07/th...
- jeffreypalermo.com/2008/08/th...
- jeffreypalermo.com/2013/08/on...
Clean architecture, Uncle Bob:
- blog.cleancoder.com/uncle-bob...
Join my weekly .NET newsletter:
www.milanjovanovic.tech
Read my Blog here:
www.milanjovanovic.tech/blog
Chapters
0:00 What is the Onion architecture?
3:22 What is the Clean architecture?
5:19 Onion architecture example project
10:17 Clean architecture example project
13:11 Are these architectures different?

Наука

Опубликовано:

27 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 161

@MilanJovanovicTech 9 месяцев назад

Get the source code for this video for FREE → the-dotnet-weekly.ck.page/clean-onion

@GreatTaiwan 29 дней назад

why not just in github ?

@lollol012 9 месяцев назад

My architecture is like an Onion - it has many layers, and each time you peel one to expose a deeper layer it makes you want to cry.

@MilanJovanovicTech 9 месяцев назад

😂

@Forshen 9 месяцев назад

😂

@maacpiash 9 месяцев назад

Ah, we really needed a video on this topic, a comparison between these seemingly similar architectures. Thanks!

@MilanJovanovicTech 9 месяцев назад

Glad you liked this one :)

@yeevirgen 9 месяцев назад

Great video, also thanks for not focusing on theory only and including the example projects from the scratch. Some things are best learned with an example

@MilanJovanovicTech 9 месяцев назад

I think this aligns nicely with my way of teaching. Some theory, but more focus on practice and practical implementations

@saddamhossaindotnet 9 месяцев назад

Great video, my friend. Now I have a clear concept of those two architectures. Thanks a lot!

@MilanJovanovicTech 9 месяцев назад

Don't you think they are the same?

@sushilb7994 9 месяцев назад

Thanks Milan! Great video! It would be interesting to see Hexagonal architecture comparison as well :)

@MilanJovanovicTech 9 месяцев назад

Great suggestion!

@sotsch9280 9 месяцев назад

Its the same as the clean architecture. Just another visualization in my opinion.

@fbrunof 9 месяцев назад

I dont know why that i'm not find you before. You have videos for all of my doubts. Thankssss!!

@MilanJovanovicTech 9 месяцев назад

Happy to help 😁 Hope you enjoy the other videos :)

@d3tn3tracer 9 месяцев назад

Thank you Mr. Jovanovic. You are first one (not FirstOrDefaul :D ) who explained it so cleaner. And with demo. Good job!

@MilanJovanovicTech 9 месяцев назад

Glad it was helpful!

@RunawayYe 9 месяцев назад

A great comparison and explanation, thank you!

@MilanJovanovicTech 9 месяцев назад

Glad it was helpful!

@edwinroman30 9 месяцев назад

Nice video! I used to see it as if onion architecture were part of clean architecture! At the end, they shared some of their philosophy. Thanks, Milan!

@MilanJovanovicTech 9 месяцев назад

Yeah, they are interchangeable

@user-jg2cl6sx2p 9 месяцев назад

Hey Milan, I've just discovered your videos and really enjoying them. I was just wondering if your Visual Studio theme is something available/easy for us to use? The syntax colors appear easier on the eyes than the default theme. Thanks!

@MilanJovanovicTech 9 месяцев назад

It's VS dark theme + ReSharper syntax highlighting

@kristianaranda 8 месяцев назад

Great video Milan!!

@MilanJovanovicTech 8 месяцев назад

Thanks a lot :)

@ignacioinnovo5308 4 месяца назад

Let me congratulate you because of the videos you do. You are very clear with your explanations!

@MilanJovanovicTech 4 месяца назад

Thank you very much!

@Benke01 7 месяцев назад

Good video. 👍A couple of thoughts: * Service interfaces is useful for unit tests when services depends on other services. * Recommend also setting the respository impl classes (and others) as internal so they can't be accessed by other layers. Only keep a public class with extension methods to IServiceCollection to add them into the DI flow.

@MilanJovanovicTech 7 месяцев назад

Great suggestions 👌

@emanueltenca8368 4 месяца назад

One question here, in case of using onion architecture, service interfaces would be placed in application layer or domain layer?@@MilanJovanovicTech

@kodindoyannick5328 3 месяца назад

I like so much your approach by pratice. Thank you Milan.

@MilanJovanovicTech 3 месяца назад

Happy to hear that!

@donaldmafa 9 месяцев назад

Thanks Milan for this explanation. When building an enterprise application with lots of entities, would it be practical to use the Clean Architecture, it appears to me that you would need a lot of query handlers and commands, which is a lot of code compared to using services? Then secondly, is there a need to use a Repository pattern if using EF Core, is this not just an extra layer?

@MilanJovanovicTech 9 месяцев назад

You're free to use EF directly. It's more or less the same amount of code (+-10%) but it's in different places.

@Zainjerr 9 месяцев назад

Bro do you have any plans on making a videos series on an entire application from start to finish? frontend backend, db, containers, the whole 9 yards.

@MilanJovanovicTech 9 месяцев назад

Yes, I did that in my course

@mshahabfar 9 месяцев назад

I used to implement my feature handlers in the Application layer even though they use ORM (DbContext). But now I see you bring them into Infrasructure (Persistence) layer. Is this by the rule or it is just your approach?

@MilanJovanovicTech 9 месяцев назад

Just an idea I got from Jeffrey Palermo's original Onion Architecture repository.

@sotsch9280 9 месяцев назад

It have to be in application layer because you often want more than just use a database. If the use Case need more information or requires more than one infrastructure, you are forced to gather this in application.

@nosaanthony7310 2 месяца назад

Thank you for this wonderful video. I have been using both architecture without having a clear understanding of the disticntion between the two architecture, and this video has cleared all grey areas. I noticed the Persistent project references the Domain project, is this allowed in clean architecture? My understanding is that only the application layer should reference the domain layer, but in your exmaple I see the "Article" object spanning across all layers up to the persistent/infrastructure layer.

@MilanJovanovicTech 2 месяца назад

IMO, they're the same thing 🤷‍♂️

@trouserMuncher 7 месяцев назад

Свака част, феноменалан видео. Посебна похвала за пример, остали само теорију понављају... 60 секунди твог примера и све сам скапирао. Жив био.

@MilanJovanovicTech 7 месяцев назад

Хвала пуно. Жив био. 😁

@antonmartyniuk 9 месяцев назад

Ah, after all you did this video! Nice!

@MilanJovanovicTech 9 месяцев назад

Hope you enjoyed it!

@antonmartyniuk 9 месяцев назад

@@MilanJovanovicTech sure, I enjoy watching your videos

@lindermannla 9 месяцев назад

Milan one question, in your Clean Architecture example, in the Core/Application "layer", isn't it a conceptual flaw to create a dependency on MediatR?

@MilanJovanovicTech 9 месяцев назад

Why? It's just an in-memory messaging library

@lindermannla 9 месяцев назад

Yes, I understand it is a messaging library. But, if I wanted to use these use cases in another application, isolating it in a project, wouldn't it be better not to create this dependency, since in the other application I might not use MediatR?

@pilotboba 9 месяцев назад

@@lindermannla If you are really concerned, you could only reference Mediatr.Contracts in the application layer and then the full mediatr in the presentation (application root) layer.

@davidaltran8526 9 месяцев назад

Great video! I have the same question. Why is Automapper considered external concern but not MediatR? Using MediatR for convience is a acceptable answer :)

@pilotboba 9 месяцев назад

@@davidaltran8526 Isn't mapping usually done in the Web project/layer? Map requests to commands and entities to responses ??? I guess I could see the entity to response mapping being done in the application layer. But not where I do it.

@user-xm7sh3vw8o 5 месяцев назад

The front-end command needs to create an order and create a payment at the same time, and this operation should be logically processed at the order application layer? Or is it processing logic at the endpoint?

@MilanJovanovicTech 5 месяцев назад

You can process them both on the backend, as one transaction.

@pilotboba 9 месяцев назад

interesting. This is the first time I've seen anyone put the query handlers in the infrastructure (persistence) project. I've mostly seen the query handlers in the Application project which is also where the command handlers are. Do you see an advantage to putting them there?

@okito 9 месяцев назад

the only real reason is that your application layer doesnt need a dependency on the ORM when handlers are in persistance/infrastructure

@MilanJovanovicTech 9 месяцев назад

Avoiding a reference to any persistence mechanism in the Application layer. And continuing down that train of thought, it makes sense. For a query I usually don't care how it's implemented, I only care about the result I get back. So I can move the details of that to Infrastructure. For command handlers, I definitely care about the implementation because it has business logic, so I want it in the Application layer. This is an idea I got from Jeffrey Palermo's Onion Architecture repo, and I just adapted it to MediatR.

@pilotboba 9 месяцев назад

@@MilanJovanovicTech So your repositories implementation only have the queries needed for the command handlers? And your query handlers use EF dbcontext directly I assume? Frankly, though, I consider Queries a use case so prefer them in the UseCase (application) project. So many ways to skin the cat I guess.

@kostasgkoutis8534 9 месяцев назад

This goes very well hand in hand with the asymmetric approach DDD/CQRS follows. The write side of the application tends to be more strict and specific than the read side that can just fetch the data however it wants. Which would make the Domain project (Entites + Repositories) less significant for the read side.

@pilotboba 9 месяцев назад

@@kostasgkoutis8534Yes, I like the suggestion that there is a projection that matches each "view" in the UI so the query is nothing more than select * from CustomerSummaryView (or whatever) But, I've never got to this point.

@juliangzr4998 9 месяцев назад

Thank you!

@MilanJovanovicTech 9 месяцев назад

You're welcome!

@joaocampos9615 20 дней назад

Great video, Milan. Very practical info, rather to see your video to quickly be a up to speed, than reading a 500 pages Clean arquitecture book :P Thanks !

@MilanJovanovicTech 20 дней назад

Glad you enjoyed it!

@microtech2448 9 месяцев назад

Did you need AsNoTracking() while projecting response using select new in clear architecture example?

@MilanJovanovicTech 9 месяцев назад

Nope

@khoalong8781 4 месяца назад

Still using AsNoTracking while select immutable object. it's an indepence with clean architecute.

@DotNetFun 9 месяцев назад

Application layer acts somewhat as the request orchestrator ( calling different services using interfaces and also calling domain services/ invariants in the process). Persistence purely deals with database stuff .so shouldn't handlers related to query also be in application layer and use the repository interface ( for getting an article in this example)? This way also provides higher cohesion IMO

@MilanJovanovicTech 9 месяцев назад

What would be the value of that indirection via the repository?

@DotNetFun 9 месяцев назад

@@MilanJovanovicTechPreventing references to any external concerns in application layer ( just like the thing you did in creating an article command handler)

@expertreviews1112 8 месяцев назад

What about placing Automapper in Application layer? Doesn't that bind it with business logic? If at a later stage, another mapper or custom mapper is needed, it would require many changes to decouple old mapper and then implement new... Do you think it's better to have mapper in Infra ?

@MilanJovanovicTech 8 месяцев назад

The chances of changing a mapper are slim to none

@expertreviews1112 8 месяцев назад

@@MilanJovanovicTech agree... They are slim but can't be ruled out... I had to recently replace Automapper with a more optimized mapper as my application was very large and Automapper was taking toll on memory... That's when I realized I needed Clean Architecture as Automapper was tightly engrained with every single project... Having it in Infra helps me as I can swap out very easily

@adrianspikes6454 9 месяцев назад

I prefer 📂 s named UseCaseViaService and UseCases then individual folders for each use. More for future organizational planning.

@MilanJovanovicTech 9 месяцев назад

Expand on this with an example? I'm curious what you mean

@TrungTran-le2ht 7 месяцев назад

I have a small question. Why didn't u put the QueryHandler in the Application layer and then inject a repository (which is located in the Domain layer) into that QueryHandler? That way, you can get rid of references to DbContext (external concern).

@MilanJovanovicTech 7 месяцев назад

Repositories should return domain entities. If I use that in a query handler - it's not optimal performance. If I start returning DTOs from the repository, it starts getting too many concerns.

@ynotj5386 4 месяца назад

I was asking myself the same exact question. Imo, the not using the repository in the query handler for performance reasons argument doesn't hold water. As a matter of fact, the approach presented in this video leaks application layer specific logic, i.e. the business logic, in the external layer. The Article Service is practically mapping user input to domain entities & passing them to the Article Repository. The Query Handler should be no different; it should map domain entities returned by the repository to dtos which are then consumed by the external layers.

@ramiroalegre8183 2 месяца назад

Hey Milan, i have a question about Onion Architecture, you created a Article entity in Domain project, and you used this entity in Persistence project with ArticleRepository, this is not a problem because you are using a Code First DB but what if i use database first? My Article will be created with properties based on my database columns (SQLServer, MySQL, etc). This is a problem, because my Domain will be depends of Persistence

@MilanJovanovicTech 2 месяца назад

You can either: - Use the scaffolded model, if possible, from the Domain (probably not possible) - Map from domain to "persistence" model - Add a DbContext that uses domain model, and can persist to DB?

@masoudmotlagh6384 9 месяцев назад

thanks for the video, how to access your sample codes? github?

@MilanJovanovicTech 9 месяцев назад

Patreon or github.com/m-jovanovic

@PelFox 9 месяцев назад

11:44 I don't agree with putting the handler down in infrastructure. In that case I would rather do something like an ArticleQueryService/ArticleReadRepository that holds the queries. But regardless I find both of these architectures very bloated and see little use case of actually using them unless you are building a big monolith, which in todays world with all cloud providers you rarely do.

@MilanJovanovicTech 9 месяцев назад

What is a "big monolith"?

@NikhilThakralYeah 9 месяцев назад

IMO both these architectures become a mess within a couple of days into development. We ditched them and switched to vertical slice architecture. It has been over an year now and we now maintain huge projects with ease. It would be great if you could compare it as well. Kudos to your work.

@MilanJovanovicTech 9 месяцев назад

Within a couple of days? I've maintained CA/Onion systems for years, and they didn't become a mess. Maybe it's not the architecture, but the engineers...

@acuencadev 8 месяцев назад

@@MilanJovanovicTech "Maybe it's not the architecture, but the engineers...". Damn...

@murat.yuceer 8 месяцев назад

If you separate application service methods by class then it changes from onion to clean right? :)

@MilanJovanovicTech 8 месяцев назад

It's the same thing, either way you look at it. Using services doesn't change the architecture

@murat.yuceer 8 месяцев назад

Do you have example project without clean arch. I need startup template with onion like your paid project@@MilanJovanovicTech

@cancurva 7 месяцев назад

Do you know any Java spring channel as good as this one ?

@MilanJovanovicTech 7 месяцев назад

Nope :(

@adshtecnologia4335 9 месяцев назад

Uncle Bob didn't tell us "how to implement Clean Architecture". so for me "Architecture" is just Onion. The concept of Clean Architecture could simply be called "Clean Code Design"

@MilanJovanovicTech 9 месяцев назад

That's an odd take

@adshtecnologia4335 9 месяцев назад

@@MilanJovanovicTech It is simple, Clean Architecture does not strictly specify how to organize the outer layers. Onion Architecture, on the other hand, is more prescriptive about organizing the external layers, requiring them to contain specific infrastructure details, such as database access and UI.

@muhamotto2084 7 месяцев назад

isn't supposed that the GetArticleByIdQueryHandler in the persistence layer uses the ArticleRepository instead of using the ApplicationDbContext ??

@MilanJovanovicTech 7 месяцев назад

Why would it?

@user-xm7sh3vw8o 9 месяцев назад

The previous video was clean architecture? Adapters were replaced with Infrastructure

@MilanJovanovicTech 9 месяцев назад

Which previous video?

@PrashantShekher 5 месяцев назад

Please explain too that Clean Architecture focuses on layering, while Onion Architecture focuses on inverted layering.?

@MilanJovanovicTech 5 месяцев назад

They're the same :)

@zakraw 9 месяцев назад

Looks like I was implementing Onion Architecture instead Clean Architecture and I didn't know that. 😄

@MilanJovanovicTech 9 месяцев назад

They're the same basically... 😂

@matthayden1979 7 месяцев назад

Can't we put entities and repositories outside of domain and create a 2 separate layers among them?

@MilanJovanovicTech 7 месяцев назад

Yes

@matthayden1979 7 месяцев назад

@@MilanJovanovicTech Thanks! That won't impact the overall onion architectural style?

@matthayden1979 7 месяцев назад

@@MilanJovanovicTech Thanks! That won't impact the overall onion architectural style?

@moazalomary8123 7 дней назад

Does anyone knows why the clean architecture doesn't represent the repository (repo interfaces) in its diagram + I didn't understand the point of making a requestQuery class in the usecases then injecting the dbContext and implementing it in the infrastructure rather than just declaring GetArtictleByIdQuery method in the repo interface then implementing it in the infrastructure and using just like the other requests and request handlers in the usescases

@MilanJovanovicTech 7 дней назад

It's all about direction of dependencies. Both architectures can be interpreted and implemented in different ways.

@expertreviews1112 8 месяцев назад

These are not necessarily like for like comparisons... For eg, Onion Architecture doesn't appear to use MediatR while Clean Architecture does... In which case Clean Architecture has Application project with a library dependency on MediatR which does not make it technology agnostic... This imo should be in Infrastructure... Pls suggest

@MilanJovanovicTech 8 месяцев назад

Not necessarily, architecturally they are pretty identical. Disregard the implementation details.

@obedasante2168 6 месяцев назад

Apart from grouping features with folders what different thing does the clean architecture actually brings? It keep confusing me. Everyone implements it differently. I love onion. Simple and straight forward 😊😊

@MilanJovanovicTech 6 месяцев назад

It's all the same thing, really...

@wh33lers 2 месяца назад

I personally would argue that mediator is part of a framework. That is why I am not using it, because every usecase class will depend on that library in the end. And use cases should describe pure business logic. I get why it is very convenient, but are you not a bit hesitant regarding the hard dependency?

@MilanJovanovicTech 2 месяца назад

No, not at all. Love using MediatR.

@markokafor7432 9 месяцев назад

Nice video and explanation but there isn’t much difference based on this tutorial. Just naming and package, for the onion architecture you used services and EFcore while for the clean architecture you used command and mediatr.

@MilanJovanovicTech 9 месяцев назад

That was kind of the point ;)

@techpc5453 8 месяцев назад

@MilanJovanovicTech 8 месяцев назад

👋

@theundaddy8037 5 месяцев назад

I think it is confusing to have a use-case (GetArticleById) in the application layer, where you only define the query and the response, and the developer is expected to know to implement the handler in the persistence layer. Wouldn't it be better to define a IArticleReadRepository interface, implement it in the persistence layer, and then implement the GetArticleByIdQueryHandler in the application layer, injecting the IArticleReadRepository into it?

@MilanJovanovicTech 5 месяцев назад

Having an IArticleReadRepository defeats the purpose of GetArticleByIdQueryHandler. The GetArticleByIdQueryHandler becomes a wrapper calling an interface method. What's the value in that?

@MilanJovanovicTech 5 месяцев назад

I made a video doing something similar: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RgqCavV2cqQ.html You can see how silly it becomes

@theundaddy8037 5 месяцев назад

@@MilanJovanovicTech Thank you very much for the link! I agree, it does seem pointless to create all this unnecessary abstraction with read services, if all we are doing is running a simple query.

@alibabarahaei2229 Месяц назад

Perfect❤

@MilanJovanovicTech Месяц назад

Thanks, glad you enjoyed it

@hermesfranklin 2 месяца назад

I can't see differences, just synonyms, because all the examples I see of both have things implemented in one and not in the other, but that don't belong to the model, this takes the focus away from the comparison, it would be interesting to leave preferences aside and focus on implement the same functionalities in both, without a mediator, without a mapper, and all these things that can be implemented in both, but are not necessary to compare, especially if there is only an example of the code in Onion or Clean

@MilanJovanovicTech 2 месяца назад

Because it's the same thing

@expertreviews1112 8 месяцев назад

why not shared source code? so inconvenient :(

@MilanJovanovicTech 8 месяцев назад

I share it on Patreon

@MdFaisalMahmudShow 3 месяца назад

Im little bit confused here. Onion focus on services and clean focus on use cases. But service contains the use cases, isn't it? Then What is the difference actually, Can anyone explain it.

@MilanJovanovicTech 3 месяца назад

They're the same thing 😁

@MdFaisalMahmudShow 3 месяца назад

@@MilanJovanovicTech 💔

@pavelromashuk237 9 месяцев назад

I think Clean architecture is more complicated than described in the video. Some key points - bounded context, domain objects are missed. Domain objects are completely different in onion ad clean, in clean you can`t simply take domain object and save it.

@MilanJovanovicTech 9 месяцев назад

You don't need to use DDD to work with Onion/Clean

@saddamhossaindotnet 9 месяцев назад

Yeah! This is a good point.

@pavelromashuk237 9 месяцев назад

@@MilanJovanovicTech Yep, you are right, I messed up things.

@Forshen 9 месяцев назад

Its the same, even the dotnet channel said it. "formerly known"

@MilanJovanovicTech 9 месяцев назад

Formerly known?

@lettuceturnipthebeets790 9 месяцев назад

@@MilanJovanovicTechthey probably meant dotnet channel mentioning Clean Architecture formerly known as Onion Architecture

@Forshen 9 месяцев назад

I wanna add, that most design patterns (including architecture) are just a theory of how to do certain stuff. But its not a strict rule, so the Clean Architecture can be implemented with different outcomes.

@muthumanivelv566 9 месяцев назад

I thought both are one in the same🙄

@Forshen 9 месяцев назад

Its the same, even the dotnet channel said it. "formerly known"

@MilanJovanovicTech 9 месяцев назад

By the end of the video, you can come to that conclusion

@sotsch9280 9 месяцев назад

They are the same 😂

@user-xm7sh3vw8o 9 месяцев назад

Clean Architecture is not Domain-Driven Design?

@magashkinson 9 месяцев назад

Completely different things

@MilanJovanovicTech 9 месяцев назад

It seems not

@user-xm7sh3vw8o 9 месяцев назад

How to make a DDD architecture？@@magashkinson

@user-xm7sh3vw8o 9 месяцев назад

How to make Domain-Driven Design? @@MilanJovanovicTech

@sotsch9280 9 месяцев назад

You can combine both concepts easily

@matswessling6600 4 месяца назад

a VERY simple project. Why not show how a real world project is implemented... That will give a much better insigts in the real problems that you never need to handle in such simple examples..

@MilanJovanovicTech 4 месяца назад

Because the concepts get lost in the complexity of a large project, and you can't explain it all in a 10-15-20 min video.

@matswessling6600 4 месяца назад

@@MilanJovanovicTech I dont think so. Obviously you vcannot write that system from scratch but you can show diagrams of it and show exampkes of real code. these kind of simplified examples doesnt really help. it just fools people.

@emrahyigit 9 месяцев назад

Both architectures are trash and will be deprecated very soon anyway. But thanks for the video. (Liked)

@juliansegura5507 9 месяцев назад

Interesting take... why do you say so?

@MilanJovanovicTech 9 месяцев назад

They've been saying that for almost 20 years now.

@pilotboba 9 месяцев назад

Is it the architecture that's trash or the project organization? Code to interface not implementation is a pretty well-established OOP principle. That said, why is it "trash"? Objective evidence, please.

@sotsch9280 9 месяцев назад

Anyone saying this has no Idea imho! 😂 sorry, but this architectures keep the most basic and ever important keypoints. You will always have to deal with dependencies and layers. Have Met alot of people saying the same, watching their "architectures" and know whats their problem.. they are mostly beginners, although few of them programming for tons of years.

@wmalgoire 9 месяцев назад

Cool idea to explain differences between those two approaches👌The layer is thin.. 😁 On a personal note I'm so glad CleanArchitecture has become more popular. I'll always remember the face of the people I tried to explain/sell "Onion" architecture benefits. Lost half of them right at the beginning 🧅🤥

@MilanJovanovicTech 9 месяцев назад

Onion just sounds weird, that might be the problem 😅