Domain Driven Design дает большие возможности по созданию крупных проектов, которые в будущем становятся надежными и легко масштабируемыми. Как пройти полный проектный цикл, от бизнес-модели до AWS?

Набираясь опыта, мы все больше внимания обращаем на архитектуру построения программной системы. Любому разработчику хочется создать надежный и долговечный продукт, чтобы работа по его сопровождению и рефакторингу приносила удовольствие вместо адских мук. Не вдаваясь в дебри архитектуры и методов проектирования информационных систем, мы применим микросервисную архитектуру и методологию предметно-ориентированного проектирования на Java, а также задеплоим тестовый проект на AWS.

Что мы будем делать?

Эта статья начинает цикл, посвященный предметно-ориентированному проектированию (Domain Driven Design или DDD), Java, микросервисам и Spring Cloud. Подразумевается, что мы пишем backend-приложение на Java с использованием сопутствующего инструментария. Версии Java и фреймворков не оговариваются, но предполагается, что вы будете использовать Java 8/11 и Spring Framework 5.3.4 (в особых случаях версия будет указана). Для большей практичности мы представим выдуманный пример проекта экстренной медицинской помощи (emc, Emergency Medical Care).

Планируя проект, вы продумываете все детали своих действий. Их последовательность будет следующей:

Сначала необходимо подготовить весь необходимый для разработки проекта инструментарий:

• подготовить систему контроля версий и протестировать ее;
• создать тестовый образец проекта, на Spring Boot, прикрутить необходимые зависимости, проверить ее запустив и затем выложить в репозиторий, на GitHub;
• создать контейнер Docker и после проверки выложить его в репозиторий на GitHub;
• выполнить все необходимые манипуляции в облачном сервисе Amazon Web Services AWS.

Второй этап архитектурный. Придется немного пройтись по теории предметно-ориентированного проектирования:

• необходимо разобраться с предметной областью, ограниченными контекстами, моделями и сервисами;
• спроектировать продукт/приложение (в нашем случае это экстренная медицинская помощь).

Третий этап технический. Создадим микросервисы, следуя канонам DDD:

• исходя из проектирования, начнем создавать ограниченные контексты, артефакты, агрегаты, модели предметной области;
• создадим операции модели предметной области: входящие (команды, операции) и исходящие операции (события);
• также создадим сервисы модели предметной области: входящие сервисы, исходящие сервисы, сервисы приложения;
• по мере написания будем выкладывать проект на AWS.

Мы пройдем с читателями по всем трем этапам жизненного цикла проекта. Надеемся, это принесет вам пользу и у вас все получится.

Настраиваем Git

Вначале необходимо проделать подготовительные работы и продумать контроль версий программного кода. Мы будем использовать Git и хранить проект на сервисе GitHub. Также потребуется создать репозиторий для будущего проекта.

Устанавливаем Git

Для установки мы воспользуемся операционной системой Ubuntu (20.04 Mate). Инсталляция Git в среде Windows не настолько сложна, ее мы преднамеренно пропустим. Последовательность команд в терминале/консоли на локальном компьютере такова:

         sudo apt update sudo apt upgrade sudo apt install git # проверяем, что git установлен git --version     

У вас должна появиться информация о версии программы:

         $ git version 2.25.1     

Задаем данные пользователя

Для начала нам необходимо настроить Git, а именно задать имя пользователя и почтовый адрес:

         git config --global user.name «Your-name» git config --global user.mail «your-email@your-domain.com» # Введенные параметры конфигурации можно найти в файле .gitconfig # Проверить можно следующей командой: git config --list      

Вы должны получить примерно такой вывод:

         user.email=your-email@your-domain.com user.name=Your-name     

Создаем локальный репозиторий проекта

На своем компьютере создаем локальный каталог (если его еще нет) под названием emc (от английского – emergency medical care):

         mkdir emc # Переходим в этот каталог cd emc # Для инициализации проекта/каталога, вводим команду: git init     

Каталог нашего проекта инициализирован, настроен и находится под контролем git. Все настройки этого репозитория можно найти в скрытом внутреннем подкаталоге .git.

Создаем учетную запись на GitHub

Заходим на сайт https://github.com/ и регистрируемся. Это несложная – много времени она не отнимет.

Создаем ssh-ключи

На локальной машине должен быть установлен ssh-keygen. В командой строке генерируем ключи:

         ssh-keygen -t rsa -b 4096 -C "your-email@your-domain.com" # Проверяем: cd ~/.ssh ls -l     

Результат должен быть таким:

• id_rsa – закрытый ключ;
• id_rsa.pub – открытый ключ;
• known_hosts – при регистрации на других серверах сюда заносятся данные о подключениях.

Создаем репозиторий в своей учетной записи на GitHub

Создаем на GitHub новый репозиторий с таким же именем emc. Предварительно копируем содержимое файла id_rsa.pub из локального каталога .ssh. На GitHub в меню профиля пользователя находим пункт «SSH and GPG keys» и выбираем «New SSH key», задаем имя ключа, а в поле для ключа вставляем скопированное содержимое id_rsa.pub.

Пробуем забросить первые данные проекта в репозиторий на GitHub

         # На локальной машине, в папке вашего проекта выполняем следующие команды: git init git add . git commit -m "Initial commit" git remote add origin git@github.com:yourname/your-ptoject.git git pull origin master git push all     

Расшифруем некоторые опции команды git:

• git init – инициализируем локальный репозиторий;
• git add . – добавляем (точка означает все файлы) файлы, для отслеживания изменений;
• git touch .gitignore – в этот файл заносится список файлов, которые не будут отслеживаться на изменения;
• git remote add origin – соединим удаленный репозиторий как origin;
• git pull origin master – скачиваем последние изменения с GitHub;
• git push all – отправляем все изменения на GitHub/

Подведем итог

При использовании Git/GitHub все сводится к следующим действиям:

1. установить Git локально и проверить на работоспособность;
2. настроить ключи SSH;
3. создать аккаунт на GitHub;
4. создать локальный репозиторий;
5. создать удаленный репозиторий на GitHub;
6. зафиксировать локальные изменения;
7. отправить изменения на удаленный репозиторий (GitHub).

Дополнительные материалы • Официальный сайт, мини учебник Git • Руководство от GitHub • Git за полчаса: руководство для начинающих • Git для начинающих: основы рабочего процесса и базовые команды • Основы Git: контроль версий для самых маленьких • 11 концепций и команд git, которые заставят вас плакать • Про Git, Github и Gitflow простыми словами •

Тестируем заброску проекта Spring Boot на GitHub

Есть разные варианты использования Spring Boot: с командной строки или в составе какой-нибудь интегрированной среды разработки (IDE). Поскольку установить IDE для программиста не так уж сложно, мы преднамеренно не описываем этот процесс.

Создаем первый тестовый проект на Spring Boot

Нам необходимо протестировать работоспособность тестового проекта. Есть различные варианты написания кода на Spring Boot, мы применим STS 4 как готовый фреймворк. Его можно взять отсюда: https://spring.io/tools.

В меню файл выбираем «New», а затем «Spring Starter Project».

Затем выбираем зависимости, которые нам понадобятся, в данном случае достаточно Spring Web.

Далее нажимаем Finish и ждем завершения процесса инициализации нового проекта.

Получаем, примерно, такой проект:

Проверяем тестовый проект на работоспособность

Для теста достаточно, чтобы приложение вывело в браузере текст «Hello World!!!». В проекте создаем класс контроллер. В пакете com.barust.emc создаем новый класс HelloController.

Для компиляции и запуска, в окне Package Explorer открываем контекстное меню (правая кнопка мыши), находим пункт Run As и выбираем для запуска команду Spring Boot App.

После успешной компиляции и запуска…

…результат должен быть таким.

Фиксируем локальный репозиторий проекта и выкладываем на GitHub

В предыдущих примерах по репозиторию Git мы работали с локальной папкой ~/emc, а теперь попробуем создать новый локальный репозиторий в проекте IDE STS4. В окне Package Explorer открываем контекстное меню, находим пункт Show in и выбираем для запуска команду Terminal (в Windows это Git Bash).

У вас должно появиться дополнительное терминальное окно.

В окне терминала выполняем последовательность предыдущих git-команд:

         git init git add . git commit -m "My first commit from STS4" git remote add origin git@github.com:yourname/your-ptoject.git git push origin master # Если что-то пошло не так push-командой, попробуйте с опцией -f git push -f origin master     

Конечный результат должен быть таким:

Идем на GitHub и проверяем репозиторий:

Дополнительные материалы • ТОП-9 фреймворков для веб-разработки, Java и Big Data в 2019 году • Дорожная карта web-разработчика Java в 2019 году • Изучение Java с нуля: что должен знать junior? • Создаем приложение с чистой архитектурой на Java 11 •

Docker

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

Немного теории

Основу Docker составляют контейнеры, которые собираются из образов. Из образа вы можете создать несколько экземпляров контейнеров, которые будут отличаться портами TCP/UDP и независимостью. Также контейнеры могут взаимодействовать друг с другом. Ниже дается общая схема построения структуры Docker:

• Клиентская часть – основной механизм/программа взаимодействия с Docker посредством терминала (мы будем пользоваться интерфейсом командной строки CLI).
• Демон Docker – он же сервер Docker, управляет образами, контейнерами, сетями и томами.
• Реестр Docker – это удаленный сервер для хранения готовых шаблонов образов, Docker Hub – один из вариантов реестра.
• Docker Compose – если у вас многоконтейнерный проект, он позволяет управлять всеми контейнерами.

Надо учесть, что основу Docker составляют: образы, контейнеры и dockerfile. В dockerfile вы описываете содержимое контейнера. Обычно используются следующие инструкции:

• FROM – родительский образ;
• ENV – переменная окружения;
• WORKDIR – рабочая директория для выполнения инструкций CMD и ENTRYPOINT;
• COPY – копирование файлов и папок из вашей локальной директории в рабочую область образа;
• LABEL – инструкция информационного характера;
• RUN – запускает команды для установки пакетов и библиотек внутри контейнера;
• CMD – указывает на команду для выполнения внутри контейнера, во время запуска;
• ENTRYPOINT – также указывает на команду для выполнения внутри контейнера;
• EXPOSE – определяет порты для внешнего доступа;
• VOLUME – определяет маршрут для хранения данных и доступа к ним.

Dockerfile является как бы сердцем для Docker, указывая своими инструкциями, как построить образ.

Дополнительные материалы • Что такое Docker, и как его использовать? Подробно рассказываем • В чём разница между Docker и Kubernetes? • Понятные видеоуроки по Docker для начинающих • Виды контейнеров: когда какой использовать • Как запустить веб-приложение на Nginx в Docker • 12 друзей Docker-а – опенсорсные инструменты в помощь разработке •

Резюме

В этой статье мы подготовили основной необходимый инструментарий: Git/GitHub, SSH, Spring Boot и Docker. В следующей части цикла мы продолжим знакомство с Docker и на этом завершим подготовительный этап проекта. Думаю, это только начало – дальше будет еще интересней.