[Suggestion] Organize and group related projects or modules into folders

[ngaisteve1]

Currently, when opening the solution in Visual Studio, the "src" folder harbors an overwhelming number of projects.

I propose organizing it by grouping related modules into folders, as illustrated below.

I welcome comments from anyone with alternative suggestions on this matter.

[saptarshidas1809]

Is this an open issue? Or is it done already?

[davidfowl]

I don’t really like the sub folders do we really need them? What are “modules”?

[jimitndiaye]

This is a matter of personal preference really. I like organising projects into descriptive solution folders but some people dislike have to drill down into the folders or think it might hide certain projects at first glance.

That said as more projects get added, having a single flat list quickly becomes unwieldy IMO.

[davidfowl]

I agree it's preference, and the way it is right now is the team's preference 😄.

[jbogard]

The original organization was around service boundaries, since it was the companion to the eBook on cloud-native microservices architecture, which I was a reviewer for both the code and book:

The top-level folders under src represent groups of deployable systems/apps/packages. "Services" being the individual microservices. In a """real""" (micro)service-oriented architecture, we would never have all these projects in one solution. It's merely for illustration.

I recognize the goals of this repo are quite different than the original, but just a heads up, changing the organization to such a way that implies all the projects should live in a common solution means it's no longer a candidate as a reference for (micro)service architecture. To the point that it might be worth adding a note in the archived repo that this repo is not the intended companion for that eBook anymore.

[davidfowl]

That explains why there was so much duplication before. This project is not optimized from a code structure POV to copy these projects into different repositories. We also are planning to do big updates to the book in the coming months to target the changes made to this repository.

we would never have all these projects in one solution

I'd add some nuance. There might be several solutions in a mono repo (or maybe you would use solution filters). This creeps into the whole Microservices in mono repo vs separate repo discussion (that I would love to avoid).

[jbogard]

It's less "mono repo vs multiple repos", but more - in a microservices architecture, you don't directly pull in and debug other services code. The solution structure was there to illustrate the logical and physical boundaries between services.

The original codebase illustrated a lot of patterns that seem superfluous or duplicate, but the goal was quite different - showcasing common patterns in microservices architectures using cloud-native Azure technology.

From a documentation perspective, I'd just create a different book. If you're going to remove a lot of the microservice patterns (clear service boundaries, DDD etc), then it's no longer a microservice reference architecture, and a ton of that eBook goes away. Which is fine. @CESARDELATORRE would be able to talk more about the original goals though since it was his baby :)

I'm not arguing against the simplifications - it makes a ton of sense for showcasing Aspire and not muddying the waters with all the other concepts being illustrated.

[sorcerb]

In a """real""" (micro)service-oriented architecture, we would never have all these projects in one solution. It's merely for illustration.

Why? If you give an example of a mono repo here, it is better to separate physically different services

I think eShopOnContainers have better structure with folders.