The missing Project that fixes everything in .NET 

Really good video. I learned something useful here!

I like it overall. I think that there needs to be some kind of "information leak" from the adapter layer up to the main component layer. What happens when the API layer requires a 3rd dependency? What happens if that's a separate team maintaining that part? When will that failure be discovered? Before calling your StartAsync you can perhaps have a Verify or Assert function call on your adapter, whereby it checks itself for proper configuration (in this case, it would ensure that _someone_ registered the required injections). Another way (not mutually exclusive) is to use the actual Options pattern to have properties that the user should fill out that will make the configuration complete. e.g. options.SetBookReadStoreType() where T : IBookReadStore. In this case, the .NET DI pattern is being used almost like the Builder pattern. Another interesting project (haven't used it personally!) is something like StrongInject which can generate compile-time errors if a required injection isn't registered. Like I said, I haven't used it, but I could see it being really useful in a composition situation like you presented in the video. Great stuff! Thanks for sharing

That's very intersting, thanks for sharing. I'm not fond of having an API depend on my Infrastructure just to register its dependencies. I was thinking to refactor my project to use something similar, so your video is on point :D

Nice example of using "Dependency Inversion" (D from SOLID) to decouple components (Adapters here) from each other.

Great content, very clean, thanks and keep the goodwork👍

Interesting approach - I will think about it for my next project

Hello! Nice video! I have a question... Where should appsettings live? In the adapter project or the composition-root project?

Great video! Would be interesting to see how you would configure an real implementation of a orm or message service.

Muito bom ! Parabéns ! Vou usar isso nos próximos projetos

Really useful video. Thank you Gui

nice job Guilherme! Do you always use JB Ryder ?

I did this way and works fine for me! The only thing that I cound't understand is how make WebApplicationFactory class and ConfigureWebHost method works for integration tests with this architecture. Maybe it could be a nice topic for another video :)

How would you register entityframework, which has a ApplicationDbContext class in for example Persistence project, but also need IConfiguration?

Excellent video, this was always a problem that bodered me. Question: Are you able to run this project on VS or VSCode? Here I am getting a Failed to determine the HTTPS port for the redirect

how would you deploy this in production? what kind of app service would you create?

Really interesting. Top!

Greate content, Thank you so much for this content. But I have a question... How to deploy this application in IIS. Because console app doesn't work in IIS.🙏🙏🙏

very informative video, thank you

Excellent video

Getting back to this video after some time. So the point here is to prevent infrastructure projects referencing each other by introducing one "dirty and all knowing" project that acts as Composition Root. Following this logic, I wonder why not having these constructors just in the Composition Root - one place that knows how to build, register dependencies and run the projects.

Have you ever succeeded in deploying (to Azure Web App for instance) ? It actually doesn't look like serving any request

Olá, Gui. Como estás? Como eu faço para adicionar/instanciar no Application.API outro adapter. Pois ao fazer isso, o método RunAsync do segundo adapter não é invocado porque o primeiro fica segurando a execução. Ex: Criei dois projetos de adapter (Adapter.API, Adapter2.API), cada um com suas respectivas controllers, mas só consigo invocar um deles no Application.API. Grato, meu caro.

Nice.

@gui.ferreira Nice video and very interesting, is there a repo i will love to check it out, if you only want to separate your controllers and endpoints into a different assembles we can use the [ AddControllers().AddApplicationParts()] and pass in the types we want to use from our class library's which hold our Controllers, filters, and any thing we want to register. and remove the controller,views and other folders from the root project and move them into the class library.