Unsure if the question is too broad, or opinion based. Though will ask anyway.
I'm currency reading through Microsofts "Architecture eBook", found https://www.microsoft.com/net/learn/architecture. It has a supporting solution that is found on Github, https://github.com/dotnet-architecture/eShopOnContainers
The sample application provides different patterns to implement within your microservices, along with a collection of different technology and infrastructure.
This leads me to my question.
When looking at the Ordering.API project (https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src/Services/Ordering) the author has chose to put their Domain and Infrastructure code within separate projects to the microservice API that is using them.
This image shows 3 of the services, with the ordering one implemented with multiple projects
Oddly, the project used to be split up further; having an Ordering.Application project too, which is now part of the Ordering.API project. This out of date image in the docs demonstrates this.
Given that Microservices should be self contained in that they have a defined bounded context, and these domain models should not be used outside of this microservice what would be the benefit of structuring the project like this, as opposed to a folder structure within the Ordering.API project?