feat: Завершение e-commerce платформы (Order, Payment, Delivery) #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rrorDto in all specs
impatient0
changed the title
kesch9
reviewed
Aug 18, 2025
| .orElseThrow(() -> new DeliveryNotFoundException(orderDto.getOrderId())); | ||
|
|
||
| BigDecimal baseCost = new BigDecimal("5.0"); | ||
| BigDecimal cost = new BigDecimal("5.0"); |
There was a problem hiding this comment.
Как вариант, можно вынести в настройки все коэффициент
|
|
||
| public interface JpaPaymentRepositoryInterface extends JpaRepository<Payment, UUID> { | ||
|
|
||
| Optional<Payment> findByOrderId(UUID orderId); |
|
|
||
| Optional<Payment> findById(UUID paymentId); | ||
|
|
||
| Optional<Payment> findByOrderId(UUID orderId); |
| public interface PaymentClient { | ||
|
|
||
| @PostMapping | ||
| PaymentDto createPayment(@RequestBody OrderDto order); |
| import org.mapstruct.Mapper; | ||
|
|
||
| @Mapper(componentModel = "spring") | ||
| public interface AddressApiMapper { |
There was a problem hiding this comment.
Выносить в api mapper думаю излишни, они используется только в одном сервисе, там их и реализовать, в общий модуль не нужно
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Этот Pull Request завершает работу над e-commerce частью проекта, добавляя сервисы
order,paymentиdelivery, а также настраивая API Gateway.Что было сделано:
Реализованы новые сервисы:
order,payment,delivery. Каждый из них работает со своей выделенной БД, получает конфигурацию из Config Server и регистрируется в Eureka.Оркестратор (
order-сервис): Основной методcreateNewOrderкоординирует взаимодействие других сервисов, последовательно обращаясь кwarehouse,deliveryиpaymentдля резервации товаров, планирования доставки и создания платежа.Взаимодействие через Feign: Вся коммуникация между сервисами построена на декларативных Feign-клиентах, что делает код чистым и читаемым.
API Gateway: Настроен шлюз (
api-gateway), который теперь является единой точкой входа для всех сервисовcommerce.Архитектурные решения и компромиссы:
В процессе работы я столкнулся с несколькими сложностями, связанными со спецификацией API.
API контракты (
order.json): Изначальная спецификацияorderсервиса была немного противоречивой, смешивая синхронные и асинхронные (callback) подходы. Чтобы построить логичный и последовательный процесс создания заказа, я постарался приближённо реализовать синхронный подход в создании заказа с дальнейшей асинхронной обработкой оплаты и доставки. В связи с этим некоторые эндпойнты из спецификации оказались избыточными и были "заглушены" с ответом501 Not Implemented.Проблема "фантомных" бронирований: Для реализации полноценного синхронного SAGA-паттерна с компенсирующими транзакциями в спецификации API не хватало эндпойнтов (например, для высвобождения бронирования). В связи с этим в текущей реализации есть риск, например, создания бронированиий товаров, которые не привязаны к существующему заказу в случае, если процесс создания заказа падает уже после создания бронирования. На мой взгляд, оптимальным решением был бы переход на асинхронную, событийно-ориентированную архитектуру с компенсирующими транзакциями, но это выходило далеко за рамки текущего ТЗ.
В целом, я постарался сделать систему максимально надежной в рамках того, как мне удалось интерпретировать предложенную архитектуру.