Обработка дочерних данных с помощью микросервисов

Я пытаюсь выяснить, как лучше организовать свой код в новых проектах. Я использую микросервисный подход с .NET Core API и Angular UI.

Мне нужно обернуть голову вокруг следующего примера:

У меня есть сущность родительского уровня, Счета. В моей базе данных есть таблица Invoices, и я создаю сервис Invoices в API, который будет обрабатывать CRUD.

Каждый счет-фактура имеет отношение один-ко-многим с InvoiceDetails, что обеспечивает более глубокий уровень информации о счете-фактуре.

Я планирую сохранить InvoiceDetails CRUD в том же InvoicesService, который указан выше, так как в моей голове все сводится к этому сервису.

Это кажется достаточно простым, но я разрываюсь на сторону пользовательского интерфейса вещей. Когда я создаю свой Счет-фактуру, мне нужно также создать InvoiceDetails. Должен ли я сделать один вызов API для создания счета-фактуры, затем по возвращении сделать другой вызов для создания InvoiceDetails, или все это должно быть обработано за один вызов?

Есть ли лучший способ, которым я должен думать об этом? Я пытаюсь максимально разделить проблемы, поэтому, похоже, должен быть один контроллер API для счетов-фактур, который обрабатывает CRUD, и отдельный контроллер для InvoiceDetails.

Всего 2 ответа


Я думаю, что ваш API должен иметь конечную точку для создания счета-фактуры, содержащего список объектов InvoiceDetails. В то же время должна быть доступная конечная точка для создания одного объекта InvoiceDetail в вашем API. Think Rest API в этом случае и не очень тесно связан с потребностями одного клиентского приложения angular / реагировать / vue и т. Д.

Это обеспечит гибкость вашего API в случае, если вам понадобится пользовательский интерфейс для добавления дополнительных InvoiceDetails к существующему Invoice или новому полному объекту Invoice со всеми объектами InvoiceDetails.

Какую из этих конечных точек вы используете, должно определяться пользовательским интерфейсом или любым другим клиентом. Например, создание нового Invoice в пользовательском интерфейсе. Я бы хотел создать конечную точку Invoice со списком InvoiceDetails. Добавление InvoiceDetails к существующему Invoice Я буду использовать конечную точку для добавления объекта InvoiceDetails.

Это более индивидуальная оценка, основанная на том, чего вы пытаетесь достичь в пользовательском интерфейсе. Пользовательский интерфейс может добавить родителя со всеми своими детьми или добавить ребенка к существующему родителю.

СЕЙЧАС КАК ОБРАЩАТЬСЯ С API ИЗ UI (ОДИН ИЛИ НЕСКОЛЬКО ЗВОНКОВ)?

Наличие нескольких вызовов API из пользовательского интерфейса для добавления одного и одного объекта InvoiceDetails при создании счета-фактуры может быть проблемой синхронизации между пользовательским интерфейсом и API. Допустим, вы успешно добавили 7/10, но не остальные 3, потому что что-то пошло не так, тогда вам, возможно, потребуется политика повторных попыток и сохранить состояние, которое было успешным или нет для отображения в пользовательском интерфейсе? Как насчет производительности?

Я бы порекомендовал один вызов API при создании объекта «Счет-фактура», который либо будет успешным, либо неудачным и облегчит управление связью между клиентом пользовательского интерфейса и API.


С точки зрения управляемой доменом разработки это будет зависеть от того, что такое сущность / совокупность в вашем бизнес-домене. В настоящее время InvoiceDetails похожи на объект Value, который не требует собственной идентичности, что говорит о том, что ему не нужны собственные веб-API CRUD.

Один из способов взглянуть на этот вопрос - спросить себя, имеет ли смысл, чтобы InvoiceDetails существовал сам по себе. Имеет ли смысл создавать InvoiceDetails без привязки к какому-либо счету? Если да, то, вероятно, целесообразно иметь отдельную конечную точку API для управления ресурсом InvoiceDetails. Если нет, то каковы основания для создания другой конечной точки для InvoiceDetails?


Есть идеи?

10000