Clean Architecture vs Vertical Slice Architecture

[@CodeOpinion]

Well done. I would say however in terms of team experience, I would argue that VSA doesn't require less experience. The reason being is that you're more open ended to how you implement anything. If and with CA you're handcuffed or as I like to say "in a box" about how you implement within each layer, as they are already defined. As you mentioned at the beginning VSA can go sideways if everything is implemented differently, that kind of proves the point. It also doesn't imply you aren't using patterns. Arguably you're probably using many of the same patterns as CA. I'd say you need to be more aware and constantly looking at the system and how features are being developed. I don't suggest consistency for the sake of consistency but more-so that if you evolve over time, features over time are going to look different on how their implemented, and that's a good thing. Anyways, well done.

[@gui.ferreira]

My take is that it requires less experience to feel productive in adding features. Usually, in something such as CA, you will notice the impact of experience after some time. "Inconsistency" over time, sounds good to me as well. It's part of the benefit. My concern is "inconsistency" due to individual preferences or knowledge, to be honest. And thanks for the comment. I'm a long-time subscriber 😉

[@marna_li]

I tend to combine these styles - you can still keeping the domain layer separate if you need to test or re-use. Since technically, you can split your monolithic application into slices by modules and then features. And when you need to make a module into its own microservice that would be quite easy. What is important when mixing is understanding the pros and cons - especially dependencies (what most developers have a problem with before discovering CA). And that requires you do get comfortable (or uncomfortable) with one or another before making the decision. The point is not to lock yourself in for the future.

[@gui.ferreira]

I agree. Both styles have many aspects in common. For that reason, it's easier to morph one into the other.

[@carlosbaptiste2062]

I appreciate this explanation and applaud your contributions to the software development community. Obrigado!

[@gui.ferreira]

Thank you, Carlos! You are one of my first Patrons. Thank you for keeping me going 😉

[@Eamo-21]

What a great video Gui! Nice to see you here as well as on X

[@gui.ferreira]

Hey Eamon! I hope you are doing fine! Glad you liked it

[@huguesviens]

We have ported very large application to clean architecture for the last few years and we love it. I had a look at the newer slice architecture but it did not found it was an improvement. Your video perfectly encapsulate why, thanks for the analysis :)

[@gui.ferreira]

Great to hear! Thank you 🙏

[@exconeer]

Thanks for explaining these two architectures. I have better understanding now.

[@gui.ferreira]

Great to hear! Thanks 🙏

[@korayenko]

When your code starts to raise events I think it would be harder to manage complexity in slices. I mean when your slice is CreatePayment and when your handler success, now you should also touch your order, warehouse, notification sub systems and the structuring of clean arc makes it easier to manage.

[@gui.ferreira]

The tricky part is when there are no clear boundaries between slices. And you are correct, events make that harder to manage.

[@JohnMarsing]

I like VSA because it has less layers I have to wrap my head around. It would be nice if there was better tooling or templates to guide developers so that each slice would have a high degree of familiarity. Thanks for the video

[@gui.ferreira]

Thanks for adding that! I like your idea but I'm that it would defeat part of the goal of VSA.

[@AboutCleanCode]

I understood that VSA has very strong focus on code being "packaged by feature" and that those vertical feature slices should be very independent but do you really think there should be no shared code at all? I didn't found a clear "definition" so far, did you? thx

[@gui.ferreira]

It's not a hard line and ideally, you extract "real duplication". One common shared piece is the domain model when present. VSA is a "plastic" architecture. In my opinion, due to its approach, the end result will be extremely different depending on the developer's years of experience.

[@nilsmach6399]

You should read the Clean Architecture book by Robert C. Martin. Then you would know, that vertical slicing is an important part of Clean Architecture.

[@gui.ferreira]

@@nilsmach6399 kzbin.info/www/bejne/laqte4WkZ8SGfMksi=5IKfEhpYJzbxZNUl&t=252

[@Tamer_Ali]

Thanks a lot Gui, you awesome. looking for more topics about them

[@gui.ferreira]

Glad you like it!

[@herewegotoday]

Would you say it's generally a good idea to start with VSA and as the application evolves and you see patterns, refactor into CA if needed?

[@gui.ferreira]

I believe that starting with VSA with CA in mind won't work. The idea of VSA is to accept that things will be different and the goal is to not get back to a feature that is working to support another.

[@MorphologicalGeek]

As a visual learner, some diagrams that help explain the architecture and its structure, would really help.

[@gui.ferreira]

Thanks for the feedback

[@equaco]

This would have been better with following a requests journey in the code.I have worked with both approaches, in the code example it kinda looks like its about folder and project structures,how many of them..But as you mentioned both of them can have different structures so it kind of blurs the point..Nice video, but its not very clear to me on first watch.

[@gui.ferreira]

Thanks for the feedback!

[@rcastillo8686]

cant you create a shared folder where things like models or utils shared across features live?

[@gui.ferreira]

In Vertical Slices? If you find duplication, and the duplicated code shouldn't evolve separately, you can.

[@mariosk2139]

VSA can be a mess if applied in large projects. The solution will result into a huge repo with unlayered, unstructured chunks of code which is hard to navigate or maintain (not talking from a hypothetical stand point. Been there/done that and it wasn't pretty). Additionally, VSA is avoiding setting real rules and teams are not always producing good results when 0 rules are defined :). My opinion: Just go with CleanArchitecture. If it starts getting complicated, this would be a good indication that you need to break into 2 separate solutions. This will result into one CleanArchitecture structure per feature (or if you prefer a modular monolith, just create fully isolated feature folders within the same solution)

[@gui.ferreira]

I would say the classic "It depends". Even CA can bring more complexity than needed.

[@Qrzychu92]

I would say you were doing VSA wrong :) what do you mean 0 rules? Just add rules. Plus, VSA doesn't mean "do whatever you want as long as it works". It's similar to TDD - red, green, REFACTOR. You make your slice according to the rules (where to put types, how do you handle validation etc - it should be consistent between slices), and then refactor away the code smells. Is this part duplicated? Yes. Is it the same code, meaning I want all duplicates to behave the same when I change something? Refactor into a service. If not, just keep duplication. The biggest problem VSA solves is coupling - you "fix" one endpoint, and 3 others are affected - that's what you get with Clean Architecture. If you don't skip on the refactor step in VSA, you will end up with Clean Architecture in each slice, if you create a set of rules, every slice will look familiar, with all shared logic nicely encapsulated somewhere on the side, and your domain objects being as close to DDD as you want. It all depends on how much time you spend refactoring

[@rtzzz9772]

what a mess