Vertical Slice Architecture - Jimmy Bogard
Vložit
- čas přidán 9. 07. 2024
- Don't forget to check out our links below!
ndcporto.com/
ndcconferences.com/
Moving from a layered architecture to a vertical slice architecture can be a bit daunting. We remove abstractions, complex structures, and focus building on the axis of change, then what's next? What new structures, patterns, and policies will need to be introduced in this style of architecture? How will we deal with common business functionality, and where do concepts like CQRS and DDD fit in?
In this session, we'll introduce the idea of vertical slice architectures, and dive into the patterns, tools, and techniques used with slices. We'll also cover how you can fit vertical slices into different kinds of systems, from desktop, SPA, and normal MVC applications. Finally, we'll look at some of the new challenges that come with slices and layers, and how a different approach provides a much more maintainable end result. - Věda a technologie
I'm looking forward implementing vertical slicing, because I also experienced the pain of N-tier kind of layering. However, this doesn't negate the need for clean or onion style architectural layers, because they serve a different purpose - reusability and replaceability of larger architectural/infrastructural/presentational components. From what I've seen so far, the vertical slicing (which seems to be essentially the encapsulation of use cases) goes hand in hand with modern layering techniques, because the command/query handlers can be neatly placed in the core's application layer, just above the domain. This is how Jason Taylor's clean architecture solution template also implements it.
But I'm really happy with 'vertical slicing' as a concept; I think it's quite neatly named. It's just a shame to see how common is the misinterpretation of MediatR as 'CQRS'. The fact that the queries and commands are separated is a completely insignificant detail in most cases, and the meat of the pattern is indeed the vertical slicing.
How did it go?
@@FudgeYeahLinusLANdid you try it yourself? How did it go? 😁
I am now at the stage of learning Architecture/Design, and under a few videos asked several people this question. And no one replied 😅
Excellent presentation! It helped me nail down the concept of CQRS.
Thank you Jimmy, loved it.
Another great presentation. Thank you for your mediaR library
Fantastic!!
What's the benefit of using CQRS? The same idea can be accomplished by actions in controllers calling "mini services" which contain only one behavior. To me it seems that splitting things into commands, queries and having a dispatcher dispatch events just complicate things. You get a complicated chain of commands if the application is big enough.
I understand where you are coming from. For me, the dispatcher is completely separate from the separation. You don't need it for cqrs. The benefit of separation though improves the single responsibility by moving each 'function' of your mini services into its own class
Since each 'function' may need different dependencies, you don't have these mini services injected with a bunch of depencies that not every function needs.
Great observation! This is where we’re at with some of my companies apps. There is an http layer around a MediatR layer which interacts with an ORM layer. It does provide a level of abstraction so we can independently change the public API from the internals, and the http layer only provides http specific mappings to internal API calls, but it’s just become another N-tier app based on these newer concepts.
@jimmy I'm wondering now with minimal API if the EndPoint just becomes the handler and we can drop the need to use mediatr to service locate a hander for a request so the endpoint becomes the "handler". I guess this won't work will if you want both an API and an MVC app to reuse the same handlers. But, if your project is only an API seems like it would be fine and remove yet one more layer and level of "magic".
I wish there was source code provided in the description
Are tests part of the slice or does it warrant a separate project? This is in consideration with how easily most CI/CD pipelines discover the tests.
Great talk Jimmy! It is great to see how yall are approaching software architecture nowadays. Seeing the evolution in thinking definitely helps to frame what problems these ideas are solving. Is there a sample project somewhere showing some of these techniques?
James Hoiby your answer on my comment got “lost” somehow. I would be really interested in your opinion.
David Garcia, in addition to Jimmy's GitHub site, for a great example of combining Jimmy's techniques with modern architecture in a practical application I HIGHLY recommend you watch Jason Taylor's video "GOTO 2019 • Clean Architecture with ASP.NET Core 3.0". Jason has good examples on GitHub as well.
@@mymacaintwag I have replied in your original thread.
@@jameshoiby Thanks James, I'll check it out!
Presentation was great and I enjoyed it very much, but audio is terribly annoying. I just wish that the quality of audio was better.
You can watch this too from 2 years ago, before covid-19; it's totally the same. I was actually hoping for some differences or updates, but I didn't notice anything.
This is great stuff! Thank you! If Domain classes are EF Core Entities, is it a good idea to have logic and validation embedded in them?
7:17 DDD
14:55 Queries and Command (CQRS)
At 11:00, honestly, even without vertical slicing, I probably would have implemented a fluent builder to build up the query. :P
03:20 shouldn't use web forms aspx since 2015? lol,
my uni to this day still teaching *Web Development* with only aspx web forms and code behind with zero OO concept.
Same here.. lol
The idea of architecture is very interesting, but for now I will not consider it for use in my projects. Loved Jason Taylor's Clean Architecture concept
Jason is simply using and applying this concept from Jimmy. It is the exact same thing, which Jimmy blogged about and coined the term (Vertical Slice Arch) around 6 years ago.
I never understood why one would create a specific repository for each entity instead of just using the IQueryable interface directly in the service layer. Imho there is no value being added with a repository. Saying that it wouldn't be unit testable otherwise isn't true either. An IQueryable interface is perfectly unit testable. Most ORMs even provide an in-memory database for this purpose.
IQueryable objects are easy to leak without realizing it.
I completely agree. When you have something as powerful as Linq (where Linq doesn't care if you're querying a database, a collection, a stream...), why not just use it in stead of adding an extra layer of unnecessary complexity?
In a previous project I did, we got rid of the extra layer and just used the IQueryable directly to:
a) query only the needed fields (immediately hydrating to the class(es) that we actually needed)
b) filter / sort / paginate directly without having to go through the entire song and dance of handing them to a repository and letting the repository perform the logic.
Using the repository pattern, IMO, only makes sense if you've got extremely complex querying logic that would otherwise need to be duplicated all over the place (which is rarely the case). And even in that case, I'd just create a form of "transformer" that takes an IQueryable and returns an IQueryable where all of the joining logic has already been done. Performance COULD become an issue, but leave that for when it moves from being a hypothetical concern to an actual concern.
VSL seems like serverless APIs.
Confusing situation...!!
I think you went a little bit overboard with splitting code into INPUT -> HANDLE -> RESPONSE. If you think about it, this is what a normal function does. Input are the parameters, handle is the code inside the function and response is what you return. You complained about low cohesion in the layered architecture but instead recreated it inside your vertical slice by doing things this way.
Splitting the code into queries and commands is good, since commands and queries will most often have different dependencies. I think you should have kept the layered architecture and just splitted your code this way instead. There is nothing forcing you to use the same dependencies between the commands/queries.
My guess is that your failure with the layered architecture comes more from the difficulty of identifying and splitting your code into separate bounded contexts.
1. Is I/o buried in the handler or always injected?
2. Testing the implementation details really sounds like wasting a lot of time.
You really lost me, when you said you wanted to go quickly over testing and in addition show this in my humble opinion poor testing Szenario. This would all make sense to me, if you would Unit Test the handlers.
Anyways, great inspiration and great talk, though not the silver bullet I hoped for for the reasons explained above.
John, I deleted my original comment because as the video progressed I liked Jimmy's ideas on unit testing better than mine. I unit test my CQRS handlers and domain classes, and rely on a few integration tests to make sure the vertical slices are healthy. Jimmy espouses skipping the unit tests on the handlers and relying on the vertical integration tests to test them. Really it seems like either approach should be fine.
Because I implement all I/O in infrastructure assemblies I use interfaces in the application layer and inject the I/O implementations with .net Core's built-in constructor dependency injection.
Ever since I discovered Jimmy's CQRS with MediatR pattern a few years ago I've been in love with it. For a great example of combining Jimmy's techniques with modern architecture in a practical application I HIGHLY recommend you watch Jason Taylor's video "GOTO 2019 • Clean Architecture with ASP.NET Core 3.0". Jason has good examples on GitHub as well.