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!

  • Deploying each service with a 10mb "Domain" DLL filled with assemblies it will never load is not desirable. -- Why? Commented Mar 28, 2017 at 18:46
  • @RobertHarvey Maybe it should have read "seems undesirable." I think this is undesirable because it may mean either different versions of the DLL exist across each microservice container, or each microservice container must be updated with each change to the code base -- even if unrelated to the microservice. Am I off base? I feel like -- ideally -- the service is deployed with nothing more than it needs. I'm still trying to figure out some of the nuances here.
    – Daniel
    Commented Mar 28, 2017 at 21:12
  • 1
    Deploying DLL's with common functionality isn't exactly controversial. Commented Mar 29, 2017 at 0:21

2 Answers 2


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.

  • 2
    +1 for the internal nuget feed. We were able to leverage this to great effect for our large number of small, focused websites. (Not so different from a number of microservices)
    – RubberDuck
    Commented Jun 28, 2017 at 22:16
  • How-to do internal nuget feeds for consumption by any service using Azure Devops and Git and VS 2019 Community ?
    – Kiquenet
    Commented Apr 15, 2021 at 10:48

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.