Vertical Slice Architecture Myths You Need To Know!
Вставка
- Опубліковано 9 лип 2024
- As with anything that gains traction from a wider community, some misconceptions develop and spread. Vertical slice architecture falls into that trap. Don't worry. I've got you covered to demystify some common misconceptions and why they likely exist. Let's set the record straight.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Наука та технологія
Learn more about Software Architecture & Design by subscribing to my newsletter.
🚀mailchi.mp/63c7a0b3ff38/codeopinion
2:02 - it depends. If you have the same concept validated in the same way in 2 different features, this works. You might also have the same concept with different forms in each feature, requiring different validation. These details can only be fleshed out by learning about the business.
2:30 - Vertical slicing can have layers. VS is a way or organizing code.
5:00 - If you have such coupling, make sure you have a middleman, so you don't end up coupling them. Try to communicate a little bit indirectly, if you expect these features to change frequently. If they will not change or change rarely (again, you need to learn the business to know this), you could probably get away with a little bit more, but I'd still advise to favour low coupling.
6:00 - Messaging is a way to decouple features, but not the only one. Messaging should be implemented in a MicroS architecture because you have to deal with different systems.
6:50 - Use cases can be just CRUD operations, but not always. The mistake I see on some project is people forcing a problem to fit a pattern, instead of understanding the problem, providing a testable solution and then analyzing if some parts could be replaced by patterns.
Thank you! You are addressing many of my concerns. I see a lot of examples of VSA using CRUD. That is kind of lazy. If your Use Cases are CRUD then it is fine. But devs should not fall into the CRUD trap when building business apps.
It always comes back to the fundamental, well-known principles of software architecture called (high) cohesion and (low) coupling, no matter whether you choose Vertical Slices, Hexagonal, Onion, or Clean Architecture, which are just different approaches.
Agreed!
The VSA is a data centric architecture. The intention is that the slices share only the data (or an abstraction of them). If you start adding shared components like your "shared validation" layer, you will end up very fast in spaghetti code.
The idea of having layers used to be "what happens if the customer asks me to change a behavior in "many" features which proved to be unlikely.
VSA focuses in the more likely situation where the customer asks to change a behavior in "one" feature.
Now, if you need to change this in 2 or more features they should be 2 or more changes requests.
The only exception is when you need to change the data schema because of one feature. That could affect many features, and that's when typed data structure (provided by EF) and feature tests come to help.
I love how you de-dogmatize stuff, man. Great video!
I like to think of VSA as an approach that mainly gained traction because a lot of developers do not see the value in infinite dogmatic abstractions as it's usually done with Clean Architecture. It's nice to see that you clean up with some myths akin to "What do I need to do to be VSA-compliant?" - That's the nice thing, there is nowhere near as much to follow 1:1 as with onion arch in order to achieve the architecture goals. If one feature is as simple as implementing it with a straightforward one or two file minimal api, while another one requires a more clean-architecture like abstraction setup, then I'm free to do just that. But the key is that I don't have to put up with abstractions to comply with a guidance if it adds no value in the end. It's a pragmatic approach suited to deal with the dynamic nature of changing requirements, instead of trying to do everything perfect upfront. At the end clean architecture and vertical slice are not mutually exclusive, but I can pick what I feel is useful instead of having it shoved down my throat.
Well said.
I am a huge fan of Vertical Slice Architecture atm, so i love this video, every point you made was spot on.
Great Topic Derek!
When people first learn about some pattern, or technique, there is a tendency to think there is only one perfect way to exercise it.
Maybe it’s the 80/20 rule for these capabilities. Real life gets in the way and it does take having a more nuanced understanding to get you to your goal.
Videos like this help to demonstrate architecture as an engineering science and an art form.
Hi Derek, Thanks for the video! 1:38 in that example of shared layer I think the common question is: should I share it or maybe it is worth of doing a code duplication so we do not depend on another project dll or nuget package in particular projects/modules.
Excuse me, I would like to inquire about the usage of Test-Driven Development (TDD) in the context of slice architecture. Is it more challenging to implement unit tests when employing this architectural approach?
In my opinion, I wouldn't even call vertical slicing an architecture. At least to me, architecture implies it is prescriptive in some way. Whereas vertical slices is more just the natural manifestation of following the principle of high cohesion and low coupling. It doesn't make other architectures obsolete as it is often desirable to follow those architectures within a vertical slice.
I'd agree with that, sorta. I made sure to make reference to it explicitly in the video, is that VSA, Clean, Event Driven, etc, are all concepts you can pick and choose what you apply that ultimately make up your specific architecture. So when people ask "what architecture do yo use?" my answer would be Buffet Architecture. ua-cam.com/video/8B445kqSKwg/v-deo.html
Thanks 👍
Good morning Derek, I was curious about the two books in the background on top of the table. I believe one of them is "Domain-Driven Design" by Eric Evan. What is the other book?
The Art of Community
Ok, so within a boundedcontext/microservice ,features are independent components/classes within the application layer which is, of course client of domain model?
I wouldn't say independent. I would say features are specific use-cases that provide some type of business capability. You can have a grouping of features that can be closely related. As well as you may have a feature that's dependent on another feature apart of some type of workflow. The point however is you're focusing on capabilities/features and organizing code code around that at for forefront.
VSA to me means: if thing A works obly with thing B, put them both in the same folder.
I havefone it in the frontend as well: in wpf with mvvm, just put all the files for a screen in s folder with the screen name.
On the micro-level, yes. This expands out farther as well into an entire service boundary and putting capabilities that relate together.
I agree with a lot of the stuff you say here, your "Code Opinion" is very sound
It's just an opinion 😜
Awesome. So I am using VSA and inside each slices I use layers. I am just playign with architecture. My question is about communication. how should the communication be? Lets say feature A needs to call some repository of feature B. Should I directly call that? Or pull that repo out of the slice and let both of the slices use it? give me some ideas please. I have been thinking about this for a while.
The question is too abstract because it depends on what and how things are related. My questions to ask are, do you need a repository? If so, what is related from A to B that's likely causing you transactional issues is my guess.
@@CodeOpinion Lets say there is no repository. But I want some data from feature A in feature B. How should this happen?
Why can't you just feature B from feature A?
If you're using some like MediatR, you can inject IMediator/ISender, and use it as normal?
According to video Features do not impact other features and Requires messaging to the decouple features. Also You can call repository every Features.
The original idea of VSA is to share the data (yes, it is a data centric architecture). The "Domain" layer shown in the video, is not a real domain, but a data abstraction layer. Usually this EF context and migrations. Now, by using EF you don't need another layer of abstraction like "Repositories", but if you want to use them, they should go into this layer as well, so you have it available in every feature.
I always thought you were advocating for micro-services and DDD. Change of direction?
I would personally never sliced my domain.
I'm an advocate for defining service boundaries around capabilities and loosely coupling the best you can between the,. I don't think I've ever really advocated for Microservices. I'd argue I think I've come off pretty harsh on synchronous service to service network calls between service boundaries.
@@CodeOpinion 100% agreed on avoiding synchronous calls in distributed systems. My point is more about slicing a bounded context. Why split the domain entities folder to the point of requiring a shared folder?
I am ok with modular monoliths but this vertical slice "thing" goes too far.
@@CodeOpinionDDD BoundedContext.
Thanks!
Share nothing
Little to no the abstraction
Low barrier to entry
Features do not impact other features
Requires messaging to the decouple features
CRUD is not use-case driven
I'm the guy who hates abstractions 👋
I'd define it as "useless" abstractions for me.
I'm also the guy who hates pointless abstractions that litter many C# code bases 👍
First
no me
@@ikotin123 This video was posted to members of my channel before it was published to the public. Hence the comment being before it was published.