Этот пост в блоге посвящен возможному способу подготовки и планирования вашего первого проекта микросервисов. В нем описываются основные шаги, которые обычно необходимо выполнить, прежде чем вы действительно сможете приступить к кодированию.
Чтобы продолжить публикацию в блоге, вам необходимо ознакомиться с:
- API REST
- Spring Boot фреймворк и знаю, как создать простой проект.
- микросервисы архитектура
ЗАЧЕМ ПЛАНИРОВАТЬ?
Когда я был внештатным разработчиком, я не слишком заботился о планировании приложения, если у меня была идея. Я бы просто составил минимальный список дел, чтобы просто отслеживать свою активность в течение дня, и сразу приступил к кодированию. Для меня этого было достаточно, так как я был тем, кто делал всю работу.
Когда вы работаете в компании, это совершенно другая история. Конечно, это зависит от компании, но в большинстве случаев вы больше не тот, кто выполняет всю работу. Обычно вас добавляют в команду разработчиков, которые собираются совместно работать над проектом.
И здесь планирование имеет решающее значение по следующим причинам :
- Каждый видит проект по-разному
- Все будут работать и вносить свой вклад в один и тот же проект
- Каждый использует разные инструменты для реализации
Если планирование выполнено правильно и правильно, все могут быть на одной странице, одинаково понимать каждую деталь проекта и использовать одни и те же инструменты для разработки.
ШАГ 1 – Определение Микросервисов
Как вы уже знаете, микросервисы – это архитектурный стиль, который структурирует приложение как набор сервисов.
Простыми словами, это множество небольших приложений, которые являются частью большого приложения. Они небольшие, независимые, просты в обслуживании и тестировании, и их может разрабатывать отдельно небольшая команда.
Хорошей практикой является определение микросервиса в соответствии с принципом единой ответственности . Это означает, что один микросервис должен отвечать только за одну задачу.
Иногда бывает трудно определить эти логические или бизнес-задачи, в некоторых случаях они очевидны (например, в интернет-магазинах определенно будет микросервис для пользователя или продукта). В любом случае, важный шаг 1 – попытаться определить их все с самого начала.
Каждый микросервис должен быть отдельным проектом Spring Boot, это хорошая практика, если мы хотим использовать разные технологии для каждого из них. Например, один из них может быть написан на Java и использовать базу данных PostgreSQL, другой может быть написан на Kotlin и использовать MongoDB.
ШАГ 2 – Определение конечных точек
После того, как мы определимся, какие микросервисы будут в нашем приложении, мы можем начать определять конечные точки для API для каждого микросервиса.
Конечная точка API простыми словами – это URL-адрес службы. Это похоже на местоположение, из которого API могут получать необходимые им ресурсы.
Один API может предоставлять несколько конечных точек. Каждая конечная точка работает через запрос и ответ – Клиент отправляет запрос и Конечная точка отправляет ответ обратно.
Обычно приложение Spring Boot запускается на localhost:8080 , поэтому, если ваше приложение, например, магазин одежды, одна из конечных точек API может быть такой:
http://localhost:8080/clothes
Когда такой URL будет получен браузером, браузер сделает запрос GET и получит взамен список одежды.
Итак, на этом втором шаге мы определяем все конечные точки для нашего приложения (например, для наиболее важных HTTP-запросов, таких как GET, POST, PUT или DELETE и т.д.).
ШАГ 3 – Определение классов
Нет, мы все еще не можем писать какой-либо код назойливо:) Я знаю, как вам не терпится начать кодирование на этом этапе, но будьте терпеливы, мы почти закончили с подготовкой.
Здесь на этом этапе мы определяем все классы, которые мы будем использовать в приложении. Теперь у нас в значительной степени есть полный обзор и четкое понимание того, что именно будет являться строительными блоками приложения.
Мы также можем записать, какие атрибуты и методы будут у каждого класса и какого типа будет каждый атрибут.
ШАГ 4 – Написание пользовательских историй
История пользователя является частью Гибкого управления проектами . Это неофициальное описание функции программного обеспечения с точки зрения конечного пользователя.
Хорошая и простая история пользователя должна быть предложением, написанным в соответствии с этим шаблоном: "Как [личность], я [хочу], [так что]".
Например: ” Как клиент, я хочу иметь возможность обновлять свою информацию, чтобы я мог изменить имя”
Когда мы разбиваем наши задачи на конкретные истории пользователей и добавляем к ним правильное описание, это означает, что любой разработчик, который будет реализовывать эту функцию, будет точно знать, что делать.
Чтобы узнать больше о пользовательских историях , вот хорошая статья – Пользовательские истории с примерами и шаблоном
ШАГ 5 – Подготовка каркасов
После того, как мы закончим со всеми вышеперечисленными приготовлениями к логике приложения, мы сможем подумать о его визуальном виде. Этот шаг важен, так как он позволяет нам визуализировать, как именно будет выглядеть наше приложение на странице.
Существуют сотни инструментов и веб-сайтов, доступных для создания эскизов/каркасов онлайн или локально (например, таких как Sketch или Figma). Существует также хороший инструмент, который позволяет сотрудничать с другими разработчиками вживую и рисовать эскиз вместе – https://excalidraw.com
Каркас помогает понять и прояснить:
- сколько страниц будет в вашем приложении
- каким будет общий макет, а также макеты для настольных и мобильных устройств вид
- как будут выглядеть верхний и нижний колонтитулы и на каких страницах они будут повторяться
- как будут выглядеть всплывающие окна
После создания каркаса каждой страницы у нас должно быть четкое понимание и представление о приложении, которое мы собираемся создать. Теперь мы можем приступить к фактическому кодированию!:)
Оригинал: “https://dev.to/olenadrugalya/how-to-plan-your-first-project-with-microservices-and-spring-boot-4bpl”