4 ms·

> Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions? I agree that having lots of proje

> Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions? I agree that having lots of projects is a pain in the ass, and projects should be used for organizing code into deployment units not for logical separation. But this isn't a feature of the language just a decision(I believe a poor one) a previous developer on your project made.

scarface74 8y ago
Projects should be used for logical separation. I think of having domain specific projects as “microservices” that are isolated and where you only interface with the module via well defined interfaces. You get the logical separation of microservices without the needless complications. If you need to share a module between teams, it’s easy to package it up as a versioned Nuget package. If you need to separate it out into its own http based microservice. It’s easy to put a Controller on top of it and create an auto generated proxy class if you are describing the API with Swagger. On the client side, have the proxy class implement the interface. Of course all this is made easier if you are using a DI framework.
- JamesBarney 8y ago
  Sure but most of the gains for microservices are splitting up large teams into independent teams responsible for sub modules which is much larger scale than most C# applications.
  - scarface74 8y ago
    The other benefit of separating functionality into microservices [1], is that it keeps developers from stepping on each other’s toes and merge conflicts. It also lets you scale independently [2]. [1] again I’m not referring to starting out with out of process microservices. They can very well be logically separated within a monolith and using class access modifiers as appropriate. [2] if you have clean namespace boundaries within your monolith, you program against interfaces instead of classes, and you use a DI framework. Pulling out an assembly/“service” from a monolith becomes a mechanical exercise.

scarface74 8y ago

Projects should be used for logical separation. I think of having domain specific projects as “microservices” that are isolated and where you only interface with the module via well defined interfaces. You get the logical separation of microservices without the needless complications. If you need to share a module between teams, it’s easy to package it up as a versioned Nuget package. If you need to separate it out into its own http based microservice. It’s easy to put a Controller on top of it and create an auto generated proxy class if you are describing the API with Swagger. On the client side, have the proxy class implement the interface. Of course all this is made easier if you are using a DI framework.

JamesBarney 8y ago
Sure but most of the gains for microservices are splitting up large teams into independent teams responsible for sub modules which is much larger scale than most C# applications.
- scarface74 8y ago
  The other benefit of separating functionality into microservices [1], is that it keeps developers from stepping on each other’s toes and merge conflicts. It also lets you scale independently [2]. [1] again I’m not referring to starting out with out of process microservices. They can very well be logically separated within a monolith and using class access modifiers as appropriate. [2] if you have clean namespace boundaries within your monolith, you program against interfaces instead of classes, and you use a DI framework. Pulling out an assembly/“service” from a monolith becomes a mechanical exercise.