Visual Studio – Organizing Solutions for Microservices

1. Quicker builds. If you have a single project for your microservice, it has to recompile everything (compiler optimizations notwithstanding). If you split your code into multiple projects, only the project you're changing and the projects that depend on it are recompiled

2. More provably decoupled code. Even in microservices with narrow, isolated functionality, the fundamentals of decoupled code still apply. When you have your different concerns in different, independent projects, it is much easier to verify that you've separated your tiers in an organized way. For example, say you're using an ORM for data access. Without using projects, how easy is it for you to prove that you're not using the ORM right in your controller? With projects, your controller is in a different binary than your data access layer, so it's pretty trivial to prove: your controller project doesn't even have a reference to it!

3. Easier unit tests. With your stuff separated out into projects, you don't have to include references to all of the crazy third party frameworks you're using for data access or web hosting when you just want to test your core business logic. Granted, in a perfect world you should have 100% code coverage, but we're not in a perfect world. The harder it is to test the simple things, the less likely it is they'll be tested.

4. Smaller deployments. .NET projects, more or less, translate to DLLs on the output side (this is a simplification, but in general, this is the end result unless you specifically avoid it). When you only change one project, you only have to redeploy one DLL. (Note that this is a terrible reason to choose projects vs. folders since you should be using automated builds/deployments anyways, but it is a reason nonetheless!)

Since you haven't included a concrete example of a case where an inconsistency could appear, I'll imagine two situations.

First situation

Let's suppose that a service handles employees and another one handles payrolls. If you call the payroll service for a new employee that has yet to be created, you're afraid that the data could become inconsistent: a payroll would be created for a person who doesn't exist yet.

In this case, moving from a monolithic application with a single database to a bunch of services, each owning its data, would not be an issue, because the payroll service could always contact the employees service to ensure that the employee exists. If not, the payroll should not be created.

Of course, you don't have the security mechanism in terms of database constraints. Nevertheless, the similar control can exist at the application level.

Second situation

A service handles payrolls and another one handles insurance information. The payroll service owns a postal address of the person, used to send the payslip. Similarly, the insurance service also has the postal addresses of the employees for its own specific needs. When an address is modified in one of the services, what guarantees that it will also be modified in the other one?

In this case, you'll usually use a third service—such as an employee service—to which two other services will delegate the responsibility of keeping the postal addresses. This way, the information is stored only once, and cannot get inconsistent.

There can be situations which are not that clear. For instance, what if a person is at the same time your employee and your customer? Should you be creating another service to handle the persons in general? Or should you allow some inconsistency (most companies would chose the second solution, which leads to a lot of situations, some funny, some particularly annoying)? There is no right choice for that: it's up to your architect to decide.

Shared database

If you consider those two situations, the shared database brings absolutely no benefit. In both situations, since each of two services is (according to you) not allowed to write to the schema of the other service, there would be no other solutions that to call the other service (first situation) or to have a third service (second situation).