I’m considering breaking up my monolith service layer into domain specific groups, which will help deployments (deploy smaller projects more often). There would be a few shared services between the separated service projects.
I know about the service gateway - the one question that’s not clear to me is how the project should be structured, especially the model classes. Do the shared dtos stay in a single project so that each project knows about them? Or should I share the source files of shared dtos using Add as Link.
This will likely come down to personal preference as whether they are added as a link and built into the same binary or not might not have much of a difference in your case, but personally I prefer using shared projects as keeping your namespace consistent and the same for your models will help you enforce the need for unique Request DTO names. Project dependencies are IMO clearer as well, where as links are a little harder to trace back.
Keeping all Request DTOs in a single namespace can ensure this is adhered to via the compiler, where as if you split them between projects, you might run into situations where you have reused a name that can cause issues for client code generation. Is a personal preference in someways, so your existing team/processes/version control might align better with linking files instead.
If the domains are cleanly distinct and separate, it might be worth considering splitting them into their own ServiceModel projects, especially if they are services that are not externally client facing. This won’t cause issues with non C# clients since you will have a separate ‘public’ API which keeps to unique Request DTO names, and use Gateways for internal communication.