Vertical Slice Architecture | The Best Architecture If… 

I was 100% agree until the very last minutes about testing. You should indeed create integration tests when there is no behavior to test : i.e for the simple queries features. But for the command features, if you have some logic, you should be testing it through the use case, not through the domain model (domain model is an implementation detail). You can do so by using the dependency inversion principle. This makes the tests very fast and deterministic and totally compatible with TDD.

I am using the exact same approach, except separating domain project. But inside domain project, still using vertical slices

Regarding testing: even if you see your slice mostly as black box I would still "simulate" the "real resources" and e.g. replace true DB with some in memory storage. This way the tests still don't know much about the internals of a slice but are still fast (enough).

Hello great content. thank you. What do you think of having each feature in a sealed assembly that can only be accessed from its command or query? I think is the cleanest aproaxh because is literaly a blackbox

Hi Gui, Thanks for the effort creating those valuable videos. A quick question to you. Is it a must to use Mediatr pattern for this? or do we have other options?

How and where you write a query that join 4 database tables in Vertical Slice Architecture?

One of the reasons we went with VSA is to have a decently scalable modular monolith that is relatively easy to break out into "feature clumps" if necessary. The other main reason we went VSA that it's waaaaay easier to debug a vertical slice than it is to debug the default clean architecture. You don't need to jump into 10 different files (API + IService + Service + IRepository + Repository + ...), it"s just all there, in the single file. If you need to change the feature, you fix, the one file, it's a no-brainer "where" you should fix the file (this is a LOT less obvious in Clean Architecture IMO, so I fix it on the controller, the service or the domain?) and you are guaranteed not to alter any of the other features in unexpected ways. The main disadvantage of this way of working is code duplication, but we try to refactor where necessary and write tests when there is code duplication, when necessary. In one of Jimmy's talks, he mentions this "feature" of VSA. When you need to unify code, there's an extra step involved. You no longer mindlessly re-use functions that are used for other features, but you need to explicitly op-in. Thus far, unless we needed to optimise performance (read, replace EF Core with Dapper or caching), we've consistently used the same frameworks across features: For commands: API call -> MediatR call -> MediatR pipelines -> Command Handler (command validation, business validation, domain state updates) -> Persistence (EF Core) -> Domain Events (Notifications) (leads to Integration Events if necessary) -> API Response For queries: API call -> MediatR call -> MediatR pipelines -> Query Handler -> EF Core or Dapper or a Cache -> API Response To know how all of our slices work, all you need to know is how API's work in .net core, a few MediatR interfaces, EF Core and Dapper. That's it. Most (if not all) of those are pretty much common knowledge nowadays.

Thanks a lot Gui for the video 👍 How to use Common Compiled Queries in Vertical Slice? Should I place then in the DbContext or create a single class for them all or create a stand alone class for their related entity and place them where they belong?

Hello !! I have a question. This approach can be used only in APIs or it can be used in a front end application also ??

In this particular case, rather then thinking in terms of integration vs unit tests, I would put the focus on the scope, i..e. coarse-grained vs fine-grained tests. For instance, having coarse-grained unit tests, i..e that involves the handler and all the dependencies (with test doubles, preferably fakes) will be very robust in terms of refactoring and should be able to exercise most of behaviours. Then you can add a small subset of coarse-grained integration tests that exercise the application boundaries and integrations, e.g. web api/controllers, databases, etc. Regarding the consistency case, it feels like more of a team decision, and it seems that it shouldn't be a problem to refactor something (no change in behaviour) to follow an equivalent and more consistent shape across the codebase.

Very well explained, Thank you. As you mentioned, lack of consistencies across the features and introducing different style of organizing codes are concerning, IMO it makes it hard for developers to get familiar with different styles of architecture introduced in each feature. it requires knowing code base very well again in terms of understanding many applied patterns. Not all engineers are in the same level and understand all patterns very well.

Would be amazing if you make a vertical slice minmal api series. The way you think/explain is very simple and easy to follow 🙌

I wonder if the feature/slice must be configured by itself, Can i reusable it later? Example I have feature and I want to use that feature in 2 places (API and CLI) or maybe more Because for CLI APP it's doesnt need the API Controller and vice versa

5:33 "The slice should be able to configure itself" Why? What is the reasoning behind this?

stop using mediatr pls, what's wrong with you