Separation of Concerns - How to separate GET/PUT/PATCH/POST/DELETE/ETC into one Microservice that gets its models and DTOs externally

0
votes

Lets say you have a typical C# .netcore webapi you are wanting to use in a microservices architecture environment. It uses entity framework connects to a SQL database, has models and DTOs.

If you want to separate the 'restfulness', the actions of actually responding to the individual GET/PUT/PATCH/POST/DELETE/ETC methods, from the data models (and into microservices) what approach would you take?

IE instead of having to create 100 microservices that each expose the same exact RESTful functionality within the APIs but each have their own specific data models and DTOs, id want to create 1 API that exposes restful GET/PUT/PATCH/POST/DELETE/ETC and separate it from static models, dtos and entitybuilder configurations. So i'd have 100 microservices concerned with passing data to the 1 REST microservice to get whatever job I need to do done in a dynamic fashion.

I am not super experienced with object oriented programming methods and I thought maybe it would be possible to have my CRUD microservice that my child microservice talks to (through an API gateway or some other method that I haven't worked out yet) pass a set of models, DTOs and entity framework entitybuilder parameters into the CRUD microservices Program.cs's Main method?

I am on the right path here?

Thank you in advance for any advise or helpful examples!!!

1
c#rest.net-coremicroservicesseparation-of-concerns
One thing that strikes me is that you think your services are alike and are 'CRUD microservices'. If you're just going to expose data objects, I think you'll end up with anaemic services and you're going to have your actual business logic somewhere else. One of the advantages of microservices is the flexibility you get and a lot of people I've talked to utilize that and make their services fit the task at hand much better than a 'one size fits all' approach. – Hans Kilian
Thank you for your feedback. It seems like you're suggesting not separating your data from your restfulness then. Appreciate your time. – ogg130
No problem. One other thing that struck me is that with 'CRUD services' it sounds like you're thinking about your system in layers. One of the things that microservices changes is that you think about 'slices' instead - that encapsulate some business logic all the way from (ideally) UI to database. I'll recommend Jimmy Bogard's excellent "Vertical Slice Architecture" article: jimmybogard.com/vertical-slice-architecture – Hans Kilian

1 Answers

1
votes

You don't. What you describe is still having a single monolith and putting 100 microservices as a facade. That makes about as much sense as ordering a large pizza and a dozen small salads as dessert because you were told that having a small salad for a meal would help you lose weight. That's not how that works.

Either look into microservices and what you gain by using that architecture, or go with your single service that does it all. Both might be valid choices, just don't pretend you are doing the other one too.