Разделение проблем - как разделить GET / PUT / PATCH / POST / DELETE / ETC в один микросервис, который получает свои модели и DTO извне

Допустим, у вас есть типичный C # .netcore webapi, который вы хотите использовать в среде архитектуры микросервисов. Он использует структуру сущностей, подключается к базе данных SQL, имеет модели и DTO.

Если вы хотите отделить «спокойствие», то есть действия по фактическому реагированию на отдельные методы GET / PUT / PATCH / POST / DELETE / ETC, из моделей данных (и в микросервисы), какой подход вы бы выбрали?

IE вместо того, чтобы создавать 100 микросервисов, каждый из которых предоставляет одну и ту же точную функциональность RESTful в API, но каждый имеет свои собственные конкретные модели данных и DTO, id хочет создать 1 API, который предоставляет спокойный GET / PUT / PATCH / POST / DELETE / ETC и отделить его от статических моделей, dtos и конфигураций entitybuilder. Таким образом, у меня было бы 100 микросервисов, связанных с передачей данных в 1 микросервис REST, чтобы выполнять любую работу, которая мне нужна, динамически.

У меня нет большого опыта работы с методами объектно-ориентированного программирования, и я подумал, что, возможно, можно будет передать мой микросервис CRUD, с которым разговаривает мой дочерний микросервис (через шлюз API или какой-либо другой метод, который я еще не разработал), для передачи набора моделей, DTO и параметров Entity Framework entitybuilder в методе Main Program.cs микросервисов CRUD?

Я здесь на правильном пути?

Заранее благодарим вас за любые советы или полезные примеры !!!


person ogg130    schedule 11.06.2018    source источник
comment
Меня поражает то, что вы думаете, что ваши сервисы похожи и являются «микросервисами CRUD». Если вы просто собираетесь раскрыть объекты данных, я думаю, вы получите анемичные сервисы, и ваша реальная бизнес-логика будет где-то еще. Одно из преимуществ микросервисов - это гибкость, которую вы получаете, и многие люди, с которыми я разговаривал, используют это и делают свои сервисы гораздо лучше, чем подход «один размер для всех».   -  person Hans Kilian    schedule 11.06.2018
comment
Спасибо за ваш отзыв. Похоже, вы предлагаете не отделять данные от состояния покоя. Цени свое время.   -  person ogg130    schedule 11.06.2018
comment
Без проблем. Еще одна вещь, которая поразила меня, - это то, что с «службами CRUD» это звучит так, как будто вы думаете о своей системе слоями. Одна из вещей, которые меняют микросервисы, заключается в том, что вы вместо этого думаете о «срезах», которые инкапсулируют некоторую бизнес-логику на всем пути от (в идеале) пользовательского интерфейса до базы данных. Я порекомендую отличную статью Джимми Богарда об архитектуре вертикального среза: jimmybogard.com/vertical-slice-architecture   -  person Hans Kilian    schedule 11.06.2018


Ответы (1)


Вы этого не сделаете. То, что вы описываете, - это все еще единый монолит и 100 микросервисов в качестве фасада. Это примерно так же разумно, как заказать большую пиццу и дюжину маленьких салатов в качестве десерта, потому что вам сказали, что небольшой салат на обед поможет вам похудеть. Это не так.

Либо изучите микросервисы и то, что вы получаете, используя эту архитектуру, либо используйте свой единственный сервис, который все это делает. Оба варианта могут быть правильными, только не делайте вид, что делаете и второй вариант.

person nvoigt    schedule 11.06.2018
comment
О, как далеко я продвинулся с тех пор, как этот вопрос новичка ... Похоже, я так и не вернулся сюда - наслаждайтесь голосом! : D - person ogg130; 10.02.2020