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.
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.
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.
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.
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.
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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-8B445kqSKwg.html
I'm confused how you can share domain models across different features. For example, if one feature displaying products on Amazon's consumer facing website vs a different feature keeping track of products in Amazon's inventory in a warehouse, whether there is inventory directly impacts how the website should display to the user so there's overlap. But there's also consumer facing information that is irrelevant for the warehouse. There's warehouse information irrelevant to the consumer. In those cases, DDD advises creating two different domain models. Some presentations about VSA I've watched will say each feature will even need it's own database and you'll need either a message queue or a scheduled task to keep the two databases eventually up to date. This seems like overkill for my small projects and also may introduce race conditions, so I've wanted to maybe get away with just using separate domain models or maybe even share parts of domain models. My thought is I could either 0. Include all info in one Product class. Based on your diagram this seems to be what you suggest on doing, but violates ISP and I may not have ALL the inventory info when I just need to display a product to the user. So it'd either require me to pull useless info and drawing unnecessary dependencies in the process or fill in lots of null values violating LSP. 1. Use inheritance. abstract Product is-a InventoryProduct or a DisplayProduct. But inheritance is the highest form of coupling and I'm also not sure that I'm sharing behavior necessary, moreso just sharing data 2. Use composition: InventoryProduct and DisplayProduct both has-a Common.ProductInfo. This is probably what I'd end up doing if I was in this situation. 3. Use one Product class and take some extra parameters to fill in the rest of the information not encapsulated by the Product class. Then put the info together to create DTOs for whatever query/mutation I need to perform. Thoughts anyone?
UI/ViewModel Composition. You don't need to replicate data everywhere but rather compose data for queries. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ILbjKR1FXoc.html
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?
Unit testing/TDD starts at the module's boundary, so your inner implementation details doesn't matter. What does matter is making the design testable. VSA will help you with that because it will be easier to determine the module's behaviors that need to be tested.
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?
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.
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'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.
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
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.
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.
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.
