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?