https://github.com/romanow/scc-orders

Order Service
https://github.com/romanow/scc-orders

kotlin spring-boot spring-cloud-contract

Last synced: 2 months ago
JSON representation

Order Service

• Host: GitHub
• URL: https://github.com/romanow/scc-orders
• Owner: Romanow
• Created: 2019-11-25T09:59:20.000Z (over 6 years ago)
• Default Branch: master
• Last Pushed: 2022-08-15T19:48:35.000Z (almost 4 years ago)
• Last Synced: 2025-03-09T15:54:31.833Z (over 1 year ago)
• Topics: kotlin, spring-boot, spring-cloud-contract
• Language: Kotlin
• Homepage:
• Size: 102 KB
• Stars: 0
• Watchers: 1
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# Order Service

```shell

# run once, it create DB services with schemas

docker compose up -d postgres

# build and run tests

./gradlew clean build

./gradlew bootRun

# open in browser http://localhost:8080/swagger-ui.html

```

# Consumer Driven Development

1. Проблемы интеграционного тестирования.


   У нас есть много микросервисов и при изменении поведения в одном мы хотим гарантировать, что не нарушается

   функциональность других. Два подхода:

    1. Развертывание микросервисов:

        1. требуется много ресурсов для прогона и в один момент времени возможен только один сценарий;

        1. на поднятие всех сервисов требуется много времени;

        1. очень сложно разбираться в ошибках.

    1. Мокировать внешние сервисы:

        1. при изменении протокола или поведения мы не можем быть уверены, что никто не отвалится.

    

1. Contract driven development (CDD):

    1. Мы создаем описание нашего контракта на Producer, по этому контракту генерируются unit-тесты на контроллеры. Тем

       самым мы гарантируем, что на Producer контроллеры обрабатывают именно такое API.

    1. После этого описание заливается в nexus (или другое хранилище артефактов, возможно локальное) или в git.

    1. На стороне Consumer поднимается легковесный сервер wiremock, для него указывается файл json, предоставленный

       Producer, в котором описаны запросы и ответы.

1. Посмотрим, как это выглядит в действии.


   Три сервиса: склад (Warehouse), заказы (Order), доставка (Delivery).

    1. Warehouse публикует контракт:

        - Получить информацию о всех вещах на складе `GET /items?page=\&size=\`

        - Зарезервировать заказ для пользователя `POST /items/take (body: { itemUids: [] })`

        - Получить информацию о вещи `GET /items/{itemUid}/state`

        - Выписать вещь со склада для доставки `POST /items/{itemUid}/checkout`

    1. Остальные сервисы на своей стороне реализуют этот контракт.

    1. На сервисах Orders и Delivery реализуем контракт и пишем тесты.

    1. Это все публикуем в gitlab и настраиваем зависимые сборки. Чтобы при изменении в сервисе Warehouse контракт

       публиковался и вызывалась переборка и прогон тестов на других сервисах/

    1. Изменяем название полей, поведение методов, добавляем или удаляем поля в запрос и ответ. Любуемся что тесты на

       других сервисах упали.

1. Есть еще один очень насущный вопрос в мире микросервисов – как бы отдать пользователю актуальную удобную

   документацию. Все, конечно, знают про OpenAPI, но часто требуют наличие какой-то бумажной или офлайн-документации.

   Для этого существует rest-docs. Описание API генерируется по тестам на API, более того, во время работы проверяется,

   что все поля в запросе и ответе описаны в документированном описании. Получается, что при описании в restdocs мы

   имеем практически описание контракта.


   Пример модуля, где фигурирует описание restdocs, показать как по нему сгенерировать groovy dsl контракт.