Разделение проблем - как разделить 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 и параметров entitybuilder entity framework в методе Main Program.cs микросервисов CRUD?
Я здесь на правильном пути?
Заранее благодарим вас за любые советы или полезные примеры !!!
Спасибо за ваш отзыв. Похоже, вы предлагаете не отделять данные от состояния покоя. Цени свое время.
Без проблем. Еще одна вещь, которая поразила меня, - это то, что с «службами CRUD» это звучит так, как будто вы думаете о своей системе слоями. Одна из вещей, которые меняют микросервисы, - это то, что вы вместо этого думаете о «срезах», которые инкапсулируют некоторую бизнес-логику на всем пути от (в идеале) пользовательского интерфейса до базы данных. Я порекомендую отличную статью Джимми Богарда "Архитектура вертикального среза": jimmybogard.com/vertical-slice-architecture
Ответы 1
Вы этого не сделаете. То, что вы описываете, - это все еще единый монолит и 100 микросервисов в качестве фасада. Это примерно так же разумно, как заказ большой пиццы и десяток небольших салатов на десерт, потому что вам сказали, что небольшой салат на еду поможет вам похудеть. Это не так.
Либо изучите микросервисы и то, что вы получаете, используя эту архитектуру, либо используйте единую службу, которая делает все это. Оба варианта могут быть правильными, только не делайте вид, что делаете и второй вариант.
О, как далеко я продвинулся с тех пор, как задал этот вопрос новичку .... Похоже, я так и не вернулся сюда - наслаждайтесь голосом за! : D
Меня поражает то, что вы думаете, что ваши сервисы похожи и являются «микросервисами CRUD». Если вы просто собираетесь раскрыть объекты данных, я думаю, вы получите анемичные сервисы, и ваша реальная бизнес-логика будет где-то еще. Одно из преимуществ микросервисов - это гибкость, которую вы получаете, и многие люди, с которыми я разговаривал, используют это и делают свои сервисы гораздо лучше, чем подход «один размер для всех».