Get the source code for this video for FREE → the-dotnet-weekly.ck.page/vsa-structure Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Something else that nobody has mentioned, it’s super easy to Wrap the entire slice in a feature flag. Which opens door for a ton of flexible development options.
Great video! A nice video you could do: - best practices C#12 - Best practices .NET 8 (top X best practices in general)… - Doing some talks on clean code…
Great video! I hope you consider creating a full video on sharing code between slices. Code duplication can be a challenging, it would be nice to see different strategies for reducing duplication.
Great stuff, Milan and also much congratz on getting MVP :) As for the video, I, personally, prefer using Clean + Vertical at the same time for non-crud apps, separating slices (folders basically) between projects. I.e "Products" folder in all projects. With enough dedication and discipline you can get best of both worlds. Great example anyway and love your approach with IEndpoint reflection stuff :)
Nice, finally I can see a good and complete VSA example! Just one question, how would you suggest using this for gRPC, given that you need to handle proto files?
Thank you for your videos. I like the vertical slice architecture. What do you think about organising vertical slice architecture with multiple "mains" like a WebAPI project and a console project. The core should be the same on both. How do you structure such a project? My answer is to make the core vertical slice architecture and the multiple main project are implementend like the hexagonal architecture which access the public interface of the core.
great video! one question, if you have another vSlice and you access the same datamodel, do you share those objects? if so, how do you manage dependencies? if not, how do you deal with rich domain models?
If sharing, use the data model from the slice where it makes most sense. Duplicating them also isn't too much of an issue, but it becomes difficult to maintain if they both need to change at the same time.
Interesting approach - but is this really feasible when things get more complicated? Would you organize a more complex project this way? I organize my vertical slices in a hierarchical folder structure - this scaled well for me so far.
Projects don't start out complicated (most of the time). They become complicated. So this is a great way to start any project, and restructure as your project grows.
@@MilanJovanovicTech OK, thanks for your response. I'd still recommend to start right with folders as no subsequent switch is required as the project grows.
In the source code, I see that AppDbContext is under Products. So does this mean there will be a DbContext instance for each vertical slice? Shouldn't AppDbContext be moved out of Products?
Hey Milan, Thank you for sharing this resource to us. However, a have a doubt: I have an entity named "Item" in selling and stock context, and if I understood well this entity can does move with cross-cutting. In this case, will are through of domain events? For example, I sold a guitar and I need to update my stock, can I create a domain event to update it?
I'm really interested in how to structure entities and their configurations in vertical slice. Should I place these two in same folder as my request command handler and response classes? Or maybe place them in different folders?
Hi Milan, thanks for the great video! I have a question though. Is there a purpose for putting the different components inside a static class (effectively the REPR pattern), as opposed to putting it in a namespace? And then reference it in the same way if you like, i.e. CreateProduct.Request, etc.. ?
Less verbose: - CreateProduct.Request/CreateProduct.Response - As opposed to CreateProductRequest/CreateProductResponse I can use simpler names within the vertical slice, where these types matter
@@MilanJovanovicTech I was thinking slightly different, calling the types still the same names, but in a folder, so: CreateProduct/ - Request.cs - Response.cs etc.
The struggle of intelligence to find the correct request together with auto includes could easily mess up the development. Having the static class wrapper hides the matching types outside of the static classes scope
I do have a hard time understanding what 'use case' implies here! Is 'use case' in the sense of requirements, as it exists in RUP? If yes, that would end up being a class diagram. However, it seems the meaning of 'use case' is different in the context of CA
A use case represents a unique piece of functionality in the system. Copy-paste from Uncle Bob's article: --- Use Cases The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case. We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns. We do, however, expect that changes to the operation of the application will affect the use-cases and therefore the software in this layer. If the details of a use-case change, then some code in this layer will certainly be affected. ---
Great Video like always :D You mentioned to map the validation result to a ProblemDetails and currently I am trying to that with the Results pattern. So map the Errors in a Result to a ProblemDetails, but I am failing misserably. Could you make a video on that, where you show, how to map the Errors of a Result to ProblemDetails within minimal API. I know it's fairly easy to that with MVC controllers, but MinimalAPI gives me a headache. My use case is that I am validating business logic and want to return custom errors. So for example CreateProducts validates if the product already exists and if it exists return Result.Fail("custom message with error details). And I want to map the Error to a problem details within minimalAPI. The controller would return something like this: return response.IsSucess ? Results.Ok() : Results.BadRequest(response.error)
Nice, but I didn't like the tip on refactoring out code duplication to a shared component. That's a premature abstraction and introduces unnecessary coupling between vertical slices. What I mean is that today's duplicate parts probably evolve in different directions in the future.
Get the source code for this video for FREE → the-dotnet-weekly.ck.page/vsa-structure
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
How to combine microservices with slices?
Something else that nobody has mentioned, it’s super easy to
Wrap the entire slice in a feature flag. Which opens door for a ton of flexible development options.
Okay, I'm liking the suggestion
Hi Milan, you produce so many interesting videos, that it takes all my day to view all of them !
Glad you like them!
Great video!
A nice video you could do:
- best practices C#12
- Best practices .NET 8 (top X best practices in general)…
- Doing some talks on clean code…
Great suggestions 👌
Great video! I hope you consider creating a full video on sharing code between slices. Code duplication can be a challenging, it would be nice to see different strategies for reducing duplication.
Yes, that's something I want to tackle
Great stuff, Milan and also much congratz on getting MVP :)
As for the video, I, personally, prefer using Clean + Vertical at the same time for non-crud apps, separating slices (folders basically) between projects. I.e "Products" folder in all projects. With enough dedication and discipline you can get best of both worlds.
Great example anyway and love your approach with IEndpoint reflection stuff :)
Thank you!
I'm doing something similar to what you are when using CA. Works great.
Thank you Milan for the easiest explanation... Can i use controller instead of map endpoint?
Yes
Nice, finally I can see a good and complete VSA example!
Just one question, how would you suggest using this for gRPC, given that you need to handle proto files?
That's a technical concern. Maybe I should do a VSA + gRPC video?
@@MilanJovanovicTech that'd be awesome, please 😃
Thank you for your videos. I like the vertical slice architecture. What do you think about organising vertical slice architecture with multiple "mains" like a WebAPI project and a console project. The core should be the same on both. How do you structure such a project? My answer is to make the core vertical slice architecture and the multiple main project are implementend like the hexagonal architecture which access the public interface of the core.
MediatR solves this pretty easily 😅
@@MilanJovanovicTech my question is how to structure such projects.
Could you do a video on Owned Properties vs EF's new Complex Types and the nuances between them?
I did: th-cam.com/video/LhCD5CUSP6g/w-d-xo.html
@@MilanJovanovicTechawesome thank you!
Could you make a video about the best practices with multithreading, async, etc?
Adding to my topic list 👌
great video! one question, if you have another vSlice and you access the same datamodel, do you share those objects? if so, how do you manage dependencies? if not, how do you deal with rich domain models?
If sharing, use the data model from the slice where it makes most sense. Duplicating them also isn't too much of an issue, but it becomes difficult to maintain if they both need to change at the same time.
Interesting approach - but is this really feasible when things get more complicated? Would you organize a more complex project this way? I organize my vertical slices in a hierarchical folder structure - this scaled well for me so far.
Projects don't start out complicated (most of the time). They become complicated.
So this is a great way to start any project, and restructure as your project grows.
@@MilanJovanovicTech OK, thanks for your response. I'd still recommend to start right with folders as no subsequent switch is required as the project grows.
pretty simple and straight forward 🤔👍
Thanks! :)
Wonderful video. Thanks much!
Thank you too!
In the source code, I see that AppDbContext is under Products. So does this mean there will be a DbContext instance for each vertical slice? Shouldn't AppDbContext be moved out of Products?
Yes we can do that. But we also don't have to. I'd move it out of the slice most likely.
Hey Milan,
Thank you for sharing this resource to us. However, a have a doubt: I have an entity named "Item" in selling and stock context, and if I understood well this entity can does move with cross-cutting. In this case, will are through of domain events? For example, I sold a guitar and I need to update my stock, can I create a domain event to update it?
to me this sounds super clean. instead of injecting a StockService or StockRepo, and all the other parts of the system that needs that info
Of course, this doesn't exclude using domain events or any other pattern
I'm really interested in how to structure entities and their configurations in vertical slice. Should I place these two in same folder as my request command handler and response classes? Or maybe place them in different folders?
Place them next to the DbContext? VSA is more about organizing around business capabilities. EF Core configurations are a minor concern.
Excellent video as always!!!!.
I appreciate that
vsa is great, love it
💪
Hi Milan, thanks for the great video!
I have a question though. Is there a purpose for putting the different components inside a static class (effectively the REPR pattern), as opposed to putting it in a namespace? And then reference it in the same way if you like, i.e. CreateProduct.Request, etc.. ?
Less verbose:
- CreateProduct.Request/CreateProduct.Response
- As opposed to CreateProductRequest/CreateProductResponse
I can use simpler names within the vertical slice, where these types matter
@@MilanJovanovicTech I was thinking slightly different, calling the types still the same names, but in a folder, so:
CreateProduct/
- Request.cs
- Response.cs
etc.
The struggle of intelligence to find the correct request together with auto includes could easily mess up the development. Having the static class wrapper hides the matching types outside of the static classes scope
Intellisense...
I do have a hard time understanding what 'use case' implies here! Is 'use case' in the sense of requirements, as it exists in RUP? If yes, that would end up being a class diagram. However, it seems the meaning of 'use case' is different in the context of CA
A use case represents a unique piece of functionality in the system.
Copy-paste from Uncle Bob's article:
---
Use Cases
The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns.
We do, however, expect that changes to the operation of the application will affect the use-cases and therefore the software in this layer. If the details of a use-case change, then some code in this layer will certainly be affected.
---
I like your approach.
Thanks
@@MilanJovanovicTech do you combine DDD with Vertical Slices, eg subdomain = slice?
@@krccmsitp2884 Most likely, yes. I'll expand on this in future videos and we can discuss possible approaches.
@@MilanJovanovicTech great!
Good Job !
Thanks!
I like the idea of vertical slice architecture. I am just worried how it would work in a large repo.
You can evolve it into anything more strict later
Hi Milan. This is great, but it can be even simpler. You don't need the repository layer (just use Dapper and DbUp).
Is the repository layer in the room with us right now?
@@drhdev years of overusing repo layers has fried this guys mind
@@drhdev HAHAHHAHAHHA
EF Core is simple enough for me
Great, thanks!
You bet!
can you compare vertical slice with clean architecture?
Yes
Great Video like always :D You mentioned to map the validation result to a ProblemDetails and currently I am trying to that with the Results pattern. So map the Errors in a Result to a ProblemDetails, but I am failing misserably. Could you make a video on that, where you show, how to map the Errors of a Result to ProblemDetails within minimal API. I know it's fairly easy to that with MVC controllers, but MinimalAPI gives me a headache.
My use case is that I am validating business logic and want to return custom errors. So for example CreateProducts validates if the product already exists and if it exists return Result.Fail("custom message with error details). And I want to map the Error to a problem details within minimalAPI. The controller would return something like this:
return response.IsSucess ? Results.Ok() : Results.BadRequest(response.error)
I talked about it here: th-cam.com/video/YBK93gkGRj8/w-d-xo.html
Thank you so much
Any time! :)
What visual studio theme is that?
ReSharper
I like it! 🎉
Awesome!
Anyone able to refactor fluent validation code into an external class, without the need to write it at every endpoint Handler method?
You could move it into a middleware
theme name??
ReSharper
Is it just me that swagger there are no operations defined in the spec using this approach?
Probably, Minimal APIs are a bit limited with Swagger
Brother Need some interview ques & ans to Crack .Net Jobs
Ok sure
What if we put all the code in the minimal/controller API method, it even omits the mediaR...🤣🤣🤣
That works also
Nice, but I didn't like the tip on refactoring out code duplication to a shared component. That's a premature abstraction and introduces unnecessary coupling between vertical slices. What I mean is that today's duplicate parts probably evolve in different directions in the future.
That's something to be decided by the developers