Organizing Visual Studio solution for microservices?

Question

We're starting to refactor one of our major products to a more microservices-oriented architecture. Presently we're using the Implementing Domain Driven Design folder structure to organize the source files. However, we're finding that the domain and infrastructure projects aren't doing a good job of organizing each microservice logically.

For example, we have the notion of a "domain event handler" that does some work when it receives a message. Presently all of those handlers are just dumped in the same "Handler" folder/namespace within "Domain". Maybe this is okay, but it feels like there's not an organizational separation between microservice contexts. Another example is our domain entities: a "member" entity may have different meanings (and even different structures) depending on its microservice context.

We're also foreseeing some troubles with deployment in the future. Obviously we want the deployment process to be as uncoupled as possible. Deploying each service with a 10mb "Domain" DLL filled with assemblies it will never load is not desirable.

Is it best to organize the source in namespaces and folders that respect the logical divisions of microservices? Should each microservice have its own solution with each of the prescribed DDD projects? Should we "move up a level in the tree" and create a solution for each node in the DDD structure, then create individual projects for each microservice?

I kind of feel like I'm in somewhat uncharted territory here and would appreciate some guidance!

Answer 1

We ultimately found that decisions made about the devops pipeline and the microservices platform will likely dictate how the Visual Studio projects and solutions are organized.

Initially, we decided one solution per microservice was the best way to go. Any common "core" libraries also had their own solutions. "Core" libraries were then hosted via internal nuget feeds for consumption by any service. This gave us the flexibility to keep services on old versions of libraries if necessary. Had we settled on Docker Swarm or Kubernetes as a platform, I think this "solution-per-service" decision would have worked out fine. However, we ended up choosing Service Fabric, which impacted our decision.

In Service Fabric, an "application" hosts a "service" (I encourage you to read more about the nomenclature if you are interested in this option). The Visual Studio solution has to be tailored somewhat to accommodate these dependencies. Depending on how you plan to scale your services, "solution-per-service" may not be an option (for reasons outside the scope of this answer).

In conclusion: pick your platform and your devops first. I think solution-per-service is ideal, but the logistics of your platform may be prohibitive.

Answer 2

Keep multiple services in the same solution may be quite ok and devops pipeline could be adjusted to support your structure.
Business boundaries should drive your design. We had logically one service, but technically it was split into 2 - web site and web api. It makes sense to keep them in the same solution, even Devops need to deploy them separately.